Cryptography-Digest Digest #462, Volume #9 Sun, 25 Apr 99 16:13:04 EDT
Contents:
Re: A question about encryption. ([EMAIL PROTECTED])
Re: 128 bit DES (David Kuestler)
Re: Thought question: why do public ciphers use only simple ops like shift and XOR?
(Sundial Services)
Re: Thought question: why do public ciphers use only simple ops like shift and XOR?
(Sundial Services)
--- sci.crypt charter: read before you post (weekly notice) (D. J. Bernstein)
Re: Can a Java or Active-x program get your keys?????? (David A Molnar)
Re: RSA-Myth (Piso Mojado)
Re: Thought question: why do public ciphers use only simple ops like shift and XOR?
(Matthias Bruestle)
Re: Prime Numbers Generator (Jim Gillogly)
Re: True Randomness & The Law Of Large Numbers (Herman Rubin)
Re: True Randomness & The Law Of Large Numbers (Herman Rubin)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: A question about encryption.
Date: Sun, 25 Apr 1999 12:43:20 GMT
<snip>
Really you are defining a cipher which has an 8 word input. Um, well if the
words were 2 bytes each this would be a 128-bit cipher. The mode of operation
(where each block are encrypted alone) is ECB or Electronic Code Book.
There are many goods ways to get started into cryptography, Applied
Cryptography is a good intro book.
If you reply in private I can email some easy read papers (.PS and .PDF) of
some ciphers. Some more complex ciphers you should leave till later.
Also read the faq, you need to know about confusion, diffusion, key
scheduling, modes of operations and other things. You should learn the
terminology which will help you phrase your questions.
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: David Kuestler <[EMAIL PROTECTED]>
Subject: Re: 128 bit DES
Date: Sun, 25 Apr 1999 13:04:27 +0000
"Gurripato (x=nospam)" wrote:
> On 22 Apr 1999 13:49:00 GMT, "dino" <[EMAIL PROTECTED]> wrote:
>
> >Hi again
> >I need some help. My customer ask a crypto application using 128 bit DES. I
> >implemented a double DES with two 64 bit keys. Is that equivalent?
> >If the answer is negative, is a triple DES with two 64 bit keys equivalent
> >to a single 128 bit DES?
> >I apologize for my poor english but i hope someone understand my question
> >:-)
> >thank you
>
> DES is really 56 bits (the other 8 are just for parity
> checking). You could combine 2 DES keys, but there�s the chance of a
> man-in-the-middle attack. 3 DES has a combined key length of 56*3=168
^^^^^^^^^^^^^^^^
meet-in-the middle
>
> bits. Even the best cryptanalytical attacks cannot crack it in less
> than about 2^112 operations.
------------------------------
Date: Sun, 25 Apr 1999 07:02:01 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Thought question: why do public ciphers use only simple ops like shift
and XOR?
> : [EMAIL PROTECTED] (Bryan G. Olson; CMSC (G)) wrote, in part:
[...]
> : However, I don't think it's appropriate to automatically conclude that
> : everyone who expresses concern about the way in which the public
> : cryptography field is going is necessarily a crank. For example, if even a
> : layperson looks at DES, or IDEA, or SERPENT, and expresses the opinion that
> : these designs all seem too regular, too repetitious, so that some form of
> : analysis at least seems like it may be someday possible ...
I think that this is basically where -I- am coming from. If you look at
the design of these Feistel ciphers, well, to me they smack of Enigma,
with its clockwork-like rotation of the cipher elements which ultimately
proved its downfall. Compare this to SIGABA, which with its many layers
of complexity "cascading" upon one another produced what is obviously an
extremely strong cipher. There is a LOT more randomness for the
cryptographer to figure out.
I stare at this "more stages = more security" story and ponder if, given
the extreme regularity of the cipher algorithm, this intuitive notion is
actually true. Frankly, I don't believe that it is.
I see no creativity here. (So to speak!!) (So to speak!!!!)
Furthermore... the ciphers are far simpler than they need to be. A
computer program can do anything. It can use as much memory as it
likes. My 2,048 bit public-key could just as easily be 200K and it
would be no more difficult to manage.
------------------------------
Date: Sun, 25 Apr 1999 07:04:08 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Thought question: why do public ciphers use only simple ops like shift
and XOR?
Sundial Services wrote:
[...]
> I think that this is basically where -I- am coming from. If you look at
> the design of these Feistel ciphers, well, to me they smack of Enigma,
> with its clockwork-like rotation of the cipher elements which ultimately
> proved its downfall. Compare this to SIGABA, which with its many layers
> of complexity "cascading" upon one another produced what is obviously an
> extremely strong cipher. There is a LOT more randomness for the
> cryptographer to figure out.
I should clarify my thought here. "The layers in SIGABA are not all the
same design. The layers in an n-round Feistel cipher are, literally by
definition, all the same. And all made of extremely simple primitive
operations: bitwise substitution, shifting, exclusive-OR, perhaps
multiplication ....
------------------------------
From: [EMAIL PROTECTED] (D. J. Bernstein)
Crossposted-To: talk.politics.crypto
Subject: --- sci.crypt charter: read before you post (weekly notice)
Date: 25 Apr 1999 05:00:35 GMT
sci.crypt Different methods of data en/decryption.
sci.crypt.research Cryptography, cryptanalysis, and related issues.
talk.politics.crypto The relation between cryptography and government.
The Cryptography FAQ is posted to sci.crypt and talk.politics.crypto
every three weeks. You should read it before posting to either group.
A common myth is that sci.crypt is USENET's catch-all crypto newsgroup.
It is not. It is reserved for discussion of the _science_ of cryptology,
including cryptography, cryptanalysis, and related topics such as
one-way hash functions.
Use talk.politics.crypto for the _politics_ of cryptography, including
Clipper, Digital Telephony, NSA, RSADSI, the distribution of RC4, and
export controls.
What if you want to post an article which is neither pure science nor
pure politics? Go for talk.politics.crypto. Political discussions are
naturally free-ranging, and can easily include scientific articles. But
sci.crypt is much more limited: it has no room for politics.
It's appropriate to post (or at least cross-post) Clipper discussions to
alt.privacy.clipper, which should become talk.politics.crypto.clipper at
some point.
There are now several PGP newsgroups. Try comp.security.pgp.resources if
you want to find PGP, c.s.pgp.tech if you want to set it up and use it,
and c.s.pgp.discuss for other PGP-related questions.
Questions about microfilm and smuggling and other non-cryptographic
``spy stuff'' don't belong in sci.crypt. Try alt.security.
Other relevant newsgroups: misc.legal.computing, comp.org.eff.talk,
comp.org.cpsr.talk, alt.politics.org.nsa, comp.patents, sci.math,
comp.compression, comp.security.misc.
Here's the sci.crypt.research charter: ``The discussion of cryptography,
cryptanalysis, and related issues, in a more civilised environment than
is currently provided by sci.crypt.'' If you want to submit something to
the moderators, try [EMAIL PROTECTED]
---Dan
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Can a Java or Active-x program get your keys??????
Date: 25 Apr 1999 13:18:13 GMT
Paul Koning <[EMAIL PROTECTED]> wrote:
>> Active-X script downloaded from the net or maybe something hidden in
>> your operating system?
> I think the answers are: Java *supposedly* not; activeX yes. So avoid
> the latter.
Did anything ever come of trying to create Java applets which would
perform timing attacks? I remember hearing speculation about it, but
do not know if anyone actually pulled it off. Certainly it seems just
on the edge of plausibility.
-David
------------------------------
From: Piso Mojado <[EMAIL PROTECTED]>
Subject: Re: RSA-Myth
Date: Sun, 25 Apr 1999 07:52:08 -1000
Anonymous wrote:
>
> Let us think RSA via PGP or similar is RSA PGP are program should come
> with a mathematical user mathematical break in the same algorithms is
> RSA and RSA approach? But this is RSA PGP program should come with a
> user to generate quasi primes it is weak either because the NSA
> Generators are to stupid to stupid to build his own and RSA approach
> are to think just because the public key from the weaknesses that the
> public Key; from the whole same algorithms is a user to think just
> because the NSA can take the NSA can take the Spooks may have to think
> to build his own and an RSA and an RSA approach?
>
> But I to build his own is RSA PGP or similar is not the weaknesses
> Generators are they are fast that allows a mathematical break in the
> low is weak. PGP or similar is not the Spooks may have to billion.
> All you know, what is weak.
But think need break idea bad. When NSA random send then cannot tell when
break finished for to send when can then send can send cannot! How many
times send that generator with random? Zero! You emphatically will never
and I repeat never, with out code which is the best. Even after RSA send
PGP send PGP not received spall chalker when Turing failure mode address
not sent as expected after.
Soon, crashing disk spalls without chalker wet net lib _DIS_ do not dis
me for to be dissed is broken to dismiss hard driven cable modem. At
28.8k baud, even the slackest disser spalls reams without broken PGP.
------------------------------
From: [EMAIL PROTECTED] (Matthias Bruestle)
Subject: Re: Thought question: why do public ciphers use only simple ops like shift
and XOR?
Date: Sun, 25 Apr 1999 15:51:42 GMT
Mahlzeit
Sundial Services ([EMAIL PROTECTED]) wrote:
> Furthermore... the ciphers are far simpler than they need to be. A
> computer program can do anything. It can use as much memory as it
> likes. My 2,048 bit public-key could just as easily be 200K and it
> would be no more difficult to manage.
But you wouldn't want to use this key. A 9000bit key needs about
15 minutes of a 486DX 33MHz CPU. I think the decryption/signing time
raises at n^2, so a 200kbit key would require about 100 hours of this
CPU. A Pentium 200MHz, not that old, is about 10 times as fast and
would require about 10 CPU hours. Would you want to wait 10 hours
to read an email?
With all crypto applications there are speed requirements.
Mahlzeit
endergone Zwiebeltuete
--
PGP: SIG:C379A331 ENC:F47FA83D I LOVE MY PDP-11/34A, M70 and MicroVAXII!
--
Remember, even if you win the rat race -- you're still a rat.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Prime Numbers Generator
Date: Sun, 25 Apr 1999 07:54:45 -0700
This is a multi-part message in MIME format.
==============A305CF00CCD157D1BCBF7048
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
David Kuestler wrote:
> I should also clarify that my program is actually two programs :
> 1) generate two files 'bytes3.dat' and 'lsb.dat' as a compression technique to
> be able to fit onto a CD, where the first 3 bytes of the 4 byte prime number is
> stored once in 'bytes3.dat' with a pointer into 'lsb.dat' which stores the 4th
> byte. ( 47 hours )
> 2) convert the 'bytes3/lsb' files into a single file ( 1 hour )
> The programs also use network byte order to store the data so the files are
> portable.
You might be able to get better compression by saving only the
differences between sucessive primes, with an occasional complete
number to allow for "random enough" access to the file, depending
on the needs of the program expected to consume this. If you
always use them in order, of course, you don't need that. I would
expect a Huffman code on the differences to be very effective, since
they will usually be fairly small. The maximum difference between
primes in this range is 336. Since they're always even, you can
divide by two and save the differences in one byte, for a file size
of 203M. A Huffman code on that alphabet of 168 characters would
undoubtedly give dramatic savings; I wouldn't be surprised if it
would all fit in under 30M. Plus, of course, the pointers that let
you get as much random access as you need.
> Your program sounds like it efficiently uses on chip cache or something special
> as I would not have expected a 400Mhz Pentium II to be over 300 times faster than
> a 233Mhz K6.
I imagine the main difference is in the algorithm rather than the
processor. For most crypto applications I find a 400 Mhz P2 to be
about three times faster than a 200 MHz P1... I'd been hoping for
more when I bought it. However, I haven't yet tried anything fancy
for optimizing caches on any of my programs.
> I would be very interested in your blocking technique if you are willing to share
> your C source code.
I guess at 83 lines it's not too big to post... lots of messages in
the "True Randomness" thread are running longer! I'm not writing them
in network order, by the way. Shall we all agree to stone the person
who invented little-endian?
--
Jim Gillogly
Mersday, 4 Thrimidge S.R. 1999, 14:12
12.19.6.2.9, 5 Muluc 17 Pop, Fourth Lord of Night
==============A305CF00CCD157D1BCBF7048
Content-Type: text/plain; charset=us-ascii; name="erato.c"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="erato.c"
/*
* erato: sieve of eratosthenes for up to 2**32.
* Two steps: first find all primes less than 2**16, then use them to sift
* the remaining numbers in blocks.
*
* Jim Gillogly, 24 Apr 1999
*/
#include <stdio.h>
#define MAXSMALL 6542 /* 6542 for primes up to 1<<16. */
#define TOP (1 << 16) /* Top of each block to be sifted. */
#define PRFILE "primes" /* Save 'em in a file. */
#define BLOCKS (1 << 16) /* How many blocks to do total? */
char sieve[TOP]; /* Turned off if composite. */
char * stop = &sieve[TOP];
unsigned long smalls[MAXSMALL]; /* All primes under 2**16. */
long smallnum = 0;
main()
{
unsigned long i, j, k, nprimes, start, step, *s;
char *p, *q;
FILE *out;
memset(sieve, 1, TOP);
sieve[0] = sieve[1] = 0; /* definition */
p = sieve;
do
{
while (++p < stop && *p == 0); /* Scan to next prime. */
q = p;
step = q - sieve;
while ((q += step) < stop)
*q = 0;
} while (p < stop);
if ((out = fopen(PRFILE, "w")) == NULL)
{
fprintf(stderr, "Phui.\n");
return 1;
}
for (i = 0, s = smalls, p = sieve; i < TOP; i++)
if (*p++)
{
*s++ = i;
fwrite(&i, 4, 1, out);
#ifdef VERBOSE
printf("%d\n", i);
#endif
}
smallnum = nprimes = (s - smalls);
printf("%d small primes.\n", smallnum);
/* Now sift each 2**16-number block with these small primes. */
start = 0;
for (k = 1; k < BLOCKS; k++)
{
start += TOP;
memset(sieve, 1, TOP); /* Clear it out. */
sieve[0] = 0;
for (i = 0, s = smalls; i < smallnum; i++) /* small primes */
{
step = *s++;
for (q = &sieve[step - (start % step)];
q < stop; q += step)
*q = 0;
}
for (i = 0, p = sieve; i < TOP; i++)
if (*p++)
{
j = i + start;
#ifdef VERBOSE
printf("%d\n", j);
#endif
fwrite(&j, 4, 1, out);
nprimes++;
}
}
fclose(out);
printf("%d primes under %lld\n", nprimes, (long long) TOP * BLOCKS);
return 0;
}
==============A305CF00CCD157D1BCBF7048==
------------------------------
From: [EMAIL PROTECTED] (Herman Rubin)
Subject: Re: True Randomness & The Law Of Large Numbers
Date: 25 Apr 1999 11:01:32 -0500
In article <[EMAIL PROTECTED]>,
R. Knauer <[EMAIL PROTECTED]> wrote:
>On Thu, 22 Apr 1999 16:02:32 +0200, Mok-Kong Shen
><[EMAIL PROTECTED]> wrote:
>>> You need to read his book.
>>This isn't a nice cooperative attitude in scientific discussions.
>>You have apprently put much effort in studying that work. I was
>>only requesting some small clarification in order to be able to
>>discuss with you. Or were you yourself not clear about the question
>>I raised?? In that case, of course, we should delete that point from
>>our discussion.
>I said you need to read the book, because that is the only way to get
>the answer to your question.
In science, books are not authorities. Quantitative scientific
models are at best approximations; there can be a close to "true
random" process as you define it, but it does not produce exactly
equidistributed independent random bits. The mathematical law is
never exactly satisfied.
................
>I have offered far more in support of my position than anyone else
>here has offered in support of the contrary position. I have offered,
>among other things, direct quotes from respected books on the subject.
>>> I gave a sketch of how one might go about certifying a radioactive
>>> TRNG several months ago. You can look it up in the archives.
>>Yes, that was employing experts to judge the engineering designs.
>>That (alone) is totally unreliable!!!
>I suggested far more than that. Just look in the archives.
You have suggested taking approximations as exact. The ideal devices
do not exist, and whatever is happening is a real, not an ideal,
situation.
Theoretical probability books, like Feller, discuss simple ideal
models. Low-level statistics texts make the mistake of acting as
if the point null hypothesis can be true. Engineers know that one
must allow for "errors". Even if the physical hypothesis, like the
constancy of the speed of light in vacuum, may be true, we do not
measure in vacuum, and the measurements are in error.
--
This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
[EMAIL PROTECTED] Phone: (765)494-6054 FAX: (765)494-0558
------------------------------
From: [EMAIL PROTECTED] (Herman Rubin)
Subject: Re: True Randomness & The Law Of Large Numbers
Date: 25 Apr 1999 11:10:27 -0500
In article <[EMAIL PROTECTED]>,
R. Knauer <[EMAIL PROTECTED]> wrote:
>On Fri, 23 Apr 1999 22:34:08 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
>wrote:
>>If R. Knauer does
>>not like the FIPS-140 monobit test for RNG testing, what test *would*
>>he like?
>Treating the TRNG as a piece of scientific equipment.
This means nothing. All pieces of scientific equipment are imprecise.
--
This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
[EMAIL PROTECTED] Phone: (765)494-6054 FAX: (765)494-0558
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
