Cryptography-Digest Digest #721, Volume #10 Sat, 11 Dec 99 01:13:00 EST
Contents:
Totally off (Re: NP-hard Problems) ("rosi")
Re: low exponent in Diffie-hellman? (Scott Fluhrer)
Re: SRP - a secure alternative for authentication >> Nice reading ... ("rosi")
Re: Ellison/Schneier article on Risks of PKI ("rosi")
Re: Digitally signing an article in a paper journal ("rosi")
New RNG Technique (Steve Harris)
Re: NSA should do a cryptoanalysis of AES (wtshaw)
----------------------------------------------------------------------------
From: "rosi" <[EMAIL PROTECTED]>
Subject: Totally off (Re: NP-hard Problems)
Date: Fri, 10 Dec 1999 22:58:24 -0500
Dear Bill,
Do not be discouraged. See there are all those intelligent people,
the issue is still so 'definite' ...
It may depend on what you were taking as the definition of NP-hard.
There is only one, right? Well, only when some ONS guy comes up
with another, even if equivalent. Else thousands of copies can float
around and nobody blinks. :)
I thought I was seeing a definition, but the very moment it went to
errata. :-\ We once were hacking out the definition of complexity.
I hope we do not do one for definition itself.
(Not personal, though I mention names for things do not get
created out of the void)
Anton held (I believe) that was a definition. Did not quake a bit
till he probably went along the pointer. Well, how can he, just in
the flash of a second, turn a definition to a non-definition?
HP was brought in as a support for the tangibility of HPh. Can
we think a bit? (Sure, redundant, by def.)
One of Safaut's post is very good, but one thing I paid special
attention: 'if NP != PSPACE' and 'it is widely believed'. Can hardly
deduce anything (but well, sure we can).
Somebody mentioned the reduction issue. I would like to bring
people's attention to the piece I said to be held firmly for people
to see. Safuat made it clear and well, if I am not mistaken, that
poly reducibility had its scope of being meaningful as far as
complexity is concerned.
It is funny that whenever, it seems, this comes up, I either get a
proof of P != NP or the cat stuff, not the Schroedinger type but much
worldly kind. (Please, not personal, but I can not help it) There is:
There are NPh ones and there are NPc ones.
Well, for all the cats in the world there are white cats. And we know
there are white ones. It did not get put the other way round: Since
there are white cats, so there are cats.
If ever (BIG IF) P = NP, we will have the ideal situation: an NP-hard
problem is a problem. Universal, absolute truth. Only that what I over-
heard about absolute truth did not sound very pleasant. :)
--- (My Signature)
Bill Unruh wrote in message <827f7i$27j$[EMAIL PROTECTED]>...
>In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (James Pate
Williams, Jr.) writes:
>
>>What are some problems that are NP-hard but not NP-complete? I know
>
>Well, it is not known if there are any NP hard problems. But assuming
>that say factoring is NP hard, I believe it is not NP complete.
------------------------------
From: Scott Fluhrer <[EMAIL PROTECTED]>
Subject: Re: low exponent in Diffie-hellman?
Date: Sat, 11 Dec 1999 03:55:07 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (jerome) wrote:
>On Fri, 10 Dec 1999 17:37:08 GMT, Scott Fluhrer wrote:
>>>Which one exactly are you speaking about ?
>>>If i understand them correctly, the 14.6.1 ones are all variations
>>>of the 'square & multiply'. I haven't look at 14.6.2(fixed exponent)
>>>and 14.6.3(fixed base) sections, are they 30% faster ?
>>>
>>I was thinking of 14.6.3, specifically. The obvious square & multiply
>>takes 1.5*lg(N) expected multiplies (where N is the exponent) while
>>14.6.3 is closer to 1.1*lg(N) expected for the range of N's we're
>>talking about.
>>
>>Ok, maybe 30% is a little over-optimistic. 25% is realistic.
>
>interresting but unfortunatly i can't use them. My application has indeed
>a fixed g and p (with g^x mod p). But i do a diffie-hellman key exchange
>with it:
>- The offer (g^x mod p) can be precomputed and used several times
> so it's cost is amortized.
>- The reply (m^x mod p with m=g^y mod p) is harder, it can't be
> precomputed or reused.
>
>To optimize my computation, i have to optimize the second case.
>I will look at the fixed exponent algorithms to see how efficient
>they are in my case.
One of us is confused. The sliding window exponentiation does evaluate
m^x mod p, with no special preconditions on m, x or p. So, why can't
you use it?
I've used it (actually, a varient of it) with DH before, and had no
problems.
--
poncho
------------------------------
From: "rosi" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: SRP - a secure alternative for authentication >> Nice reading ...
Date: Fri, 10 Dec 1999 23:18:33 -0500
Did not do the nice reading but took another look at the SRP paper.
Do not know if I am looking at an old copy. This time I went
directly to the end and was interested in the Acknowledgement
section. Disappointed. Did not see my name mentioned. Come on
Tom, I pointed out something of value. (Just kidding)
The only thing, if I am picky, is to brush the text up a bit. Just a
couple as examples.
In the Abstract, the words 'key-exchange' and 'exchaning keys' are
used. I would prefer to make a distinction between key-establishment and
key-exchange. 'Two parties exchanging different keys' is better called
key-exchange while 'two striving toward a common shared key' is better
called key establishement. (Just personal preferrence)
Visually: one is A ----> B ----> A and the other is X ----> Y ----> Z.
where B can be A, but X, Y, Z are almost always different. And of course
B and Y are sort of exposed during transit in the insecure channel.
Also, password-based and password-dependent convey slightly different
meanings. (Personal taste again). As far as SRP is concerned, due to
the intended (DH) transformation, it gives an uncomfortable feeling to
view it in the old concept of a password.
There is a bit of confusion between password and verifier. (I do not
think the author meant, in the Abstract, password database on the server,
but the verifier database on the server). There may be other places that
can be more exact to avoid confusing people new to cryptography.
It is implicit that the hash is necessarily:
for all x, y, z, H(x, y, z)=H(H(x, y), z)
Maybe too obvious, but B = v + g^b should really be B = H(v, s) + g^b?
Similarly, x being defined as 'A private key derived from the password
and salt' is not accurate. Let v = H(P, t), then x = H(P, t, s) for
some (random t) and P being the password. Of course, if we look closely,
such as going back to page 6, or looking at step 5, the relationship
between x and v seems confusing.
One other thing I find interesting is the dividing line between
encryption and non-encryption. Would it be reduced to a word game or
is there really something to it? If you can establish secrets securely,
you should be able to have secrecy WITHOUT encryption (if that means
using DES and such), am I wrong?
All in all, I am just being picky. SRP is remarkable (but not
satisfactory
to me). The only pity may be that I have nothing better.
I somehow find David Jablon's on SPEKE and related topics a better
read (just personal opinion). In fact, it is one of the nice texts I
have seen. Believe that when the paper for SRP gets refined, it will be
just as nice to read.
------------------------------
From: "rosi" <[EMAIL PROTECTED]>
Subject: Re: Ellison/Schneier article on Risks of PKI
Date: Fri, 10 Dec 1999 23:55:31 -0500
Worth reading.
As it touched one thing I had a thought on, I think I
might as well comment a bit.
The three letters sounded fancier, but seem to have a
narrower scope than I thought.
I believe it should be ok for sales people out there
trying to make a buck or two by touting it up. But I thought
that everyone in this discipline would scream seeing the
digital signature laws in Utah and Washington. If I go to
an extreme, it is not PKI, it is not I, it is not K, but it is P!
(There are other things pointed out, and I agree, I am out
of the main stream)
The paper IMO asked two major questions:
1. Do we need PKI?
2. What for?
I think there is one to ask:
0. Is there a PKI (or a bit hysterical, Can there be one?)
I have a slightly different opinion about the use and place
of such a thing under the light: People are doing e-commerce
in the old style and in the 'virtual' absence of PKI, so its
place in our life is in doubt. I think it will be very important
and people can fall in love with it like we did with the cars.
The thing I am concerned with is: what is IT? where is IT? If
you give me it, is it IT?
Lastly, the thing related in some way to me. This is basically
about Risk #7. First, what Bruce and Carl said makes good
sense. I had tried CA plus RA but in a very, very special setting.
In general, adding a RA does not help any perhaps. In special
cases (i.e. special applications) it may add some value. I am
not 100% sure. As we know, there are things, just as the very
issue of trust, that are very difficult ones to handle. I tried something,
but I am not satisfied with what I had. Anyway, I think for special
cases, if designed well, addign a RA may help. Any opinions?
--- (My Signature)
------------------------------
From: "rosi" <[EMAIL PROTECTED]>
Subject: Re: Digitally signing an article in a paper journal
Date: Sat, 11 Dec 1999 00:02:46 -0500
Dear Klorox,
Paul's is perfect. Mine in the following is a bit redundant
but just a bit more detailed for you to consider if you are
planning some 'realization'. Please ignore if you find errors
or if you just prefer to, and comments are welcome.
Let it be separated into fixed part(s) and 'free-will'
parts (i.e. "secret words" in Paul's term).
Get a random number for the total 'length' of the 'free-will'
(greater than 1 but a small integer) part(s).
Let the 'free-will' parts be some consecutive 'text' from,
say The Bible (which is public knowledge), with basic formating
stripped if applicable, i.e. only single white space if allowed
at all, no line feeds, or paragraphing. "Free-will' entails a
random indexing into the volume AND random ending
determined by the random 'length' mentioned.
For a standard, fixed small positive integer n, randomly
swap EXACTLY n 'words' in the contiguous 'text' from the volume.
Randomly chop up the contiguous chunk into the parts
mentioned where each part is at least x bits in length.
Randomly select the parts (and the 'length' in some standard,
defined and fixed encoding as an additional part) and insert them
into the fixed part at random positions.
SHA hash the resulting 'text' to 'PEN-NAME' (and if the
publisher allows such a one, you are done).
A couple of notes.
0. First, very rough sketch (of a very specific implementation)
and further details and values for some of the parameters need to
be filled in. And a general question related to pre-image: any
significance to the relation of the redundancy of the 'texts' of
the fixed and the 'free-will' parts, which is known, to the size
of the hash? To be more specific, say the best (ideal) compression
can compress the chunk, on average, to x, and the hash size is y.
Need we pay much attention to the relationship between x and y?
1. A few considerations why I have it so convoluted: A range
of possible applications including yours. Your application in
particular (including 'proving') needs not be on-line and
considering the length of the chunk needs to be hashed
(if 'length' is controlled and you do it with a computer)
should not be a problem.
2. At least one of the 'free-will' parts should be appended
at the end. Any padding needs be FIXED (say all zeros) and at the
start of the chunk to be hashed, assuming start is where the hash
starts.
3. Furthermore, if you are considering other possible
applications, you may use the hashed result as a 'key' to
scramble/hash the hashed result again, resulting in 'PEN-NAME'.
(Note, 'key' is in quotes and the word scramble is used, implying
you do not need any 'encryption').
4. I am 'strictly' mimicking Paul's, so that you need to
have the 'KEY' (secret words) to prove. In my case, your 'KEY' is
the driver for the randomness, and the 'KEY' kind of exercising
less control over the hash result, a slight difference from Paul's.
But be aware that also different from Paul's is that if you used a
King James' version, you may lose the ability to prove :). Haven't
thought too much, but any interesting issues related to giving the
publisher everything, anybody? Also, only the start and the 'end'
of the 'free-will text' need be derived from your 'KEY', other
random stuff may be independent.
6. Probably two years back, I saw somebody asking the patenting
of ideas along the same line, though in detail may be very different
from your application. It seemed to be a much broader concept, but
the person did not sound technical. Even if patented, whether the
claims covered your particular one may be a question. If anybody
has any information to share in this respect, would appreciate it.
5. Finally, the word 'PEN-NAME' kind of answered and (again)
asked the question concerning the acceptance of the publisher.
My view is that it is a question of habit and mind-setting. Any
interesting issues why this can not be accepted, anybody? (Awaring
of the point of 'contents' and am restricting my this question to
the type of contents to what you have in mind).
--- (My Signature)
------------------------------
From: [EMAIL PROTECTED] (Steve Harris)
Subject: New RNG Technique
Date: 10 Dec 1999 20:30:39 -0800
I have developed a technique that converts the output of any RNG into a
cryptographically secure bit stream good enough to pass all statistical tests
for randomness, including DIEHARD. It’s not strictly a generator in itself, but
a modifier which I call ECHO.
It has the following important features:
1.) Modifies any RNG; my example uses the C rand() function.
2.) The output is not correlated to the seed.
3.) The seed length is unlimited. My example uses a 128-bit seed.
4.) The same seed does not produce the same sequence twice, unless ECHO is reset
to its default state.
5.) There are many possible default states.
6.) After the initial run, ECHO starts in a random state.
7.) The output bits are not correlated to each other in any way. It’s not that
they don’t appear to be correlated, but they are in fact uncorrelated.
8.) ECHO does not repeat, it has a period of infinity.
8.) It ouputs bytes at a time.
9.) Entropy collection is not absolutely necessary with ECHO. A seed entered
manually is enough to make it secure.
11.) It uses less than 5K of memory.
12.) On my Pentium II 400Mhz it produces 21 Mbps.
It has the following security features:
1.) Large seed length.
2.) No input attack is possible with a manually entered seed.
3.) The operator need not know what the seed is.
4.) ECHO can start in an unknown state (dependent on the security of a data file
which is created when it’s shut down).
5.) An attacker must know the beginning state and seed of ECHO to determine the
output. Otherwise he must attempt a brute-force attack, which is infeasible.
BASIC GENERATOR
Declare an array of 4096 elements. Fill each element with a byte, from 0 to 255.
Do this 16 times. Then shuffle the array, using any RNG. For output, take the
value from each element in order. When you get to the end, shuffle it again.
Keep going as long as you like. You’ll find that this produces a bit stream good
enough to pass any test for randomness.
Here is an example of the simplified code. This program produces a file of
32-bit numbers for testing with DIEHARD. Note that this example does not include
advanced security; I’ll get to that later. The numbers in brackets refer to the
notes that follow.
// Simplified ECHO RNG //
#include <stdio.h>
#include <stdlib.h>
#define SIZE 4096 // [*** 1 ***] //
#define SEED 13126 // [*** 2 ***] //
unsigned char bytes[SIZE];
unsigned int a, b, c;
unsigned long e, f;
unsigned int count = SIZE, octet = 0;
unsigned long MAX, number = 0;
FILE *fp1;
void initialize(void);
void numgen(void);
void initialize(void)
{
// Initialize New Bytes Array //
for (a = 0; a <= ((SIZE / 256) - 1); a++) {
for (b = 0; b <= 255; b++) bytes[(a * 256) + b] = b; // [*** 3 ***] //
}
srand(SEED);
}
void numgen(void)
{
puts("\n Please Wait . . .");
for (e = 1; e <= (MAX * 4); e++) { // [*** 4 ***] //
if (count == SIZE) {
// Shuffle the Bytes Array //
for (a = SIZE; a >= 2; a--) {
do b = ((a * rand()) / RAND_MAX) + 1; while (b == (SIZE + 1));
c = bytes[(a - 1)];
bytes[(a - 1)] = bytes[(b - 1)];
bytes[(b - 1)] = c;
count = 0;
}
}
// Assemble and Store Number //
f = bytes[count];
f <<= (octet * 8);
number += f;
octet++;
if (octet == 4) {
fwrite(&number, sizeof(unsigned long), 1, fp1);
number = 0;
octet = 0;
}
count++;
}
}
void main(void)
{
initialize();
while(1) {
puts("\n\n How many numbers do you want? (0 to exit)\n"); // [*** 5 ***] //
scanf("%lu", &MAX);
if (MAX == 0) break;
if ((fp1 = fopen("\\echo.32", "wb")) == NULL) exit(0);
numgen();
fclose(fp1);
}
}
Notes:
1.) The array can be larger, if desired. It must be a multiple of 256. This is
the smallest size that gives consistently good results with DIEHARD.
2.) I chose this seed arbitrarily. Of course, it can be any unsigned integer.
2.) This is one of many possible fill patterns. One marvelous feature of ECHO is
that it’s very flexible. For example, you could fill the numbers in backwards.
Or you could use a pattern such as 16 0’s, then 16 1’s, 16 2’s, etc. This
flexibility adds up to good security. An attacker may not know how you’ve
initialized the array.
3.) For DIEHARD, you collect four bytes, then store them as a 32-bit number. For
other implementations, harvest as many bytes (or bits) as desired.
5.) You probably know that you need at least 2,867,200 numbers for DIEHARD.
SECURITY
Notice that, even with no modification at all, ECHO is somewhat secure. The
output of rand() is never directly revealed, but is disguised by the individual
byte values. The output bytes themselves have no mathematical correlation to
each other or to the seed. Thus there is no algorithm that can predict the next
bit, even if all the previous ones are known.
Note, however, that the output becomes somewhat predictable as it nears the end
of the cycle of 4096, as only a few bytes will remain to choose from. And, of
course, the 4096th byte will be 100% predictable. We’ll take care of that by
starting each cycle early, and we’ll vary the starting point randomly.
An attacker has two ways to try to break the security of ECHO:
1.) He can attempt to track the pattern of the bytes, to note the position of
each one and determine where it moves to when shuffled, and thereby to discover
the output of the underlying rand() generator. He’ll have trouble with this for
two reasons: (1) There are 16 occurrences of each byte; it’s difficult to tell
which is which. (2) As I said before, he will not receive the entire cycle of
the array as output. Some bytes will move into and out of a black hole and be
impossible to track. Plus, for this approach to work, he must know the exact
starting and ending points of each cycle, and he won’t be able to determine
them.
2.) He can use the more straightforward brute-force method. He can try every
seed, and compare the byte pattern of each one with the actual pattern. He has a
better chance with this approach, since the seed of rand() is only 16 bits long.
He may be frustrated, though, if he doesn’t know the fill pattern used, since
each one will produce a different sequence with a given seed. But let’s suppose
he does know the fill pattern. He will require, as you know, an average of 2^15
attempts to find the seed. Of course, this is trivial. If not modified, it could
be broken easily. But note that he would need all of the output to succeed at
this. If he came in somewhere in the middle of the stream, he would probably not
be able to determine the seed.
Actually, this is all moot, because ECHO has a unique feature that makes it
quite powerful. You see, rand() can be seeded more than once before generation
begins.
Here’s what I mean: Seed rand(), then shuffle the array. This produces 2^16
possible sequences. Then, before taking output, reseed it and reshuffle it. Now
there are 2^32 possible sequences, because when you reseeded rand(), you didn’t
reset the array; the new seed acts on the new pattern. Reseed it again, and
there are 2^48 sequences. You can do this as many times as desired. In my
example below, I’ve used eight seeds, or 128 bits. However, the seed length is
unlimited.
This reseeding feature comes in handy for another reason. You see, with a given
seed, ECHO would eventually begin to repeat, just like any other PRNG. But
there’s nothing that says the seed can’t be changed at any time. In fact, we’ll
change it on a regular basis, preventing ECHO from ever repeating. This is
because ECHO has the useful property that an identical seed will not produce the
same output sequence twice.
ECHO does not have to start in the same state each time it runs, either. It can
be started in an already-randomized state. When it’s shut down, the currently
active array can be stored to disk or non-volatile memory. The next time it’s
started, the same array is loaded back into memory, and the new seeds act on it.
As long as the disk file is adequately protected, the beginning state will be
secure. Even if someone gets access to the file, the unknown seed will protect
it.
Here is the improved code. Of course, this is only an example of how ECHO can be
implemented. Again, it creates files for DIEHARD.
// ECHO RNG Technique //
// by Steve Harris, 1999 //
#include <stdio.h>
#include <stdlib.h>
#define SIZE 4096
unsigned char bytes[SIZE], y_n;
unsigned int a, b, c;
unsigned int seed_count = 0, entropy = 0, count = SIZE, octet = 0 init = 0;
unsigned long e, f;
unsigned long seed[8], MAX, cycles = 1000000, number = 0;
FILE *fp1, *fp2;
void initialize(void);
void numgen(void);
void finalize(void);
void initialize(void)
{
do {
puts("\n\n Array File\n");
puts("\n 1 - Use existing file");
puts("\n\n 2 - Create new file");
scanf("%c", &y_n);
fflush(stdin);
}while (y_n != '1' && y_n != '2');
if (y_n == '1') {
c = 1;
// Fill in 'Bytes' Array Using Disk File //
if ((fp2 = fopen("echobyte.bin", "rb")) == NULL) exit(0);
for (a = 0; a <= SIZE; a++) fread(&bytes[a], sizeof(unsigned char), 1, fp2);
fclose(fp2);
// Fill In File With Dummy Values //
if ((fp2 = fopen("echobyte.bin", "wb")) == NULL) exit(0);
b = 255;
for (a = 0; a <= SIZE; a++) fwrite(&b, sizeof(unsigned char), 1, fp2);
fclose(fp2);
}
else {
c = 2;
// Initialize New Bytes Array //
for (a = 0; a <= ((SIZE / 256) - 1); a++) {
for (b = 0; b <= 255; b++) bytes[(a * 256) + b] = b;
}
}
if (c == 1) {
do {
puts("\n\n Seeding\n");
puts("\n 1 - Automatic");
puts("\n\n 2 - Manual");
scanf("%c", &y_n);
fflush(stdin);
}while (y_n != '1' && y_n != '2');
}
if (y_n == '1') {
// Automatic Seeding // // [*** 1 ***] //
for (a = 0; a <= 7; a++) {
number = 0;
for (b = 0; b <= 1; b++) {
f = bytes[(a * 2) + b];
f <<= (b * 8);
number += f;
}
if (number == 0 || number == 1) number = 2;
seed[a] = number - 1;
// printf("\n %lu", seed[a]); //
}
}
else {
// Manual Seeding //
for (a = 0; a <= 7; a ++) {
do {
printf("\n\n %u - Enter a positive integer of any length (10+ digits
recommended)\n\n", (a + 1)); // [*** 2 ***] //
scanf("%lu", &seed[a]);
fflush(stdin);
}while (seed[a] < 1);
seed[a] %= 65534; // [*** 2 ***] //
seed[a] += 1;
// printf("\n %lu", seed[a]); //
}
}
}
void numgen(void)
{
puts("\n Please Wait . . .");
for (e = 1; e <= (MAX * 4); e++) {
if (count == SIZE) {
// Shuffle the Bytes Array //
do {
if (entropy < 8 || cycles == 1000000) { // [*** 3 ***] //
srand(seed[seed_count]);
cycles = 0;
}
for (a = SIZE; a >= 2; a--) {
do b = ((a * rand()) / RAND_MAX) + 1; while (b == (SIZE + 1));
c = bytes[(a - 1)];
bytes[(a - 1)] = bytes[(b - 1)];
bytes[(b - 1)] = c;
}
cycles++;
if (entropy < 7 || cycles == 1000000) {
seed_count++;
if (seed_count > 7) seed_count = 0;
}
if (entropy < 8) entropy++;
}while (entropy < 8);
count = (255 + bytes[0]); // [*** 4 ***] //
if (init == 0) { // [*** 5 ***] //
f = seed[7];
f %= (SIZE – 510);
count = (510 + f);
init = 1;
}
}
// Assemble and Store Number //
f = bytes[count];
f <<= (octet * 8);
number += f;
octet++;
if (octet == 4) {
fwrite(&number, sizeof(unsigned long), 1, fp1);
number = 0;
octet = 0;
}
count++;
}
}
void finalize(void)
{
// Store 'Bytes' Array to Disk As 'Echobyte.bin' //
if ((fp2 = fopen("echobyte.bin", "wb")) == NULL) exit(0);
for (a = 0; a <= SIZE; a++) fwrite(&bytes[a], sizeof(unsigned char), 1, fp2);
fclose(fp2);
}
void main(void)
{
initialize();
while(1) {
puts("\n\n How many numbers do you want? (0 to exit)\n");
scanf("%lu", &MAX);
if (MAX == 0) break;
if ((fp1 = fopen("\\echo.32", "wb")) == NULL) exit(0);
numgen();
fclose(fp1);
}
finalize();
}
Notes:
1.) Automatic seeding can be used if the operator is sure the stored file has
not been compromised. I don’t know if I’d recommend this method, but it’s faster
than manual seeding. The seeds are derived from bytes which will not be revealed
in the output (see Note 4). If you want to display the seed values for testing,
remove the comments from the ‘printf’ statement.
2.) This is a technique that allows an operator to enter unknown seeds randomly
by simply punching in values from the keyboard number pad. The numbers punched
in will be converted to a seed usable by rand(). The operator need not know
(and, really, should not know) what the actual seeds are. Of course, this manual
method can be replaced with bits derived by entropy collection, if desired.
3.) The purpose of the ‘entropy’ variable is to cause the array to be shuffled
eight times (using a different seed each time) before output begins. The purpose
of ‘cycles’ is to cause reseeding after a certain number of shuffle cycles. This
prevents repetition. I’ve chosen a value of 1,000,000 cycles, which is
4,096,000,000 32-bit numbers in this case.
4.) The starting point of each cycle will vary from 255 to 510. No bytes before
the starting point will be revealed. This varying starting point has one other
beneficial effect. You may have noticed that, if unmodified, ECHO would produce
exactly as many zeros as ones in a stream of bytes that’s a multiple of 4096.
But by dropping some bytes, there will now be a slightly unequal distribution.
This will make the bit stream look more random.
5.) When ECHO first begins, the initial starting point will be some number
between 510 and 4095 (or whatever the SIZE is). This makes it extremely
difficult (if not impossible) for an attacker to determine the starting and
ending points of each array cycle, since the first reshuffle will occur earlier
than usual.
This generator has properties of both a pseudo-random and a true random
generator, so I’m not sure what category it belongs in. I guess it’s in a
category by itself.
I’m making this code available to anyone who wants to test it or use it for any
purpose. I hope it will prove a useful tool for cryptographers. I welcome any
and all comments.
Regards,
Steve Harris
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Fri, 10 Dec 1999 23:40:03 -0600
In article <82phf4$1if$[EMAIL PROTECTED]>, "Rick Braddam"
<[EMAIL PROTECTED]> wrote:
About the Big Spring doings:
>
> Wish I'd been there, I'd have loved the opportunity to learn from
> each of you. ......
Who knows where and with whom we will pop up next. David and I agree on
many things and disagree on a few, but had a wonderful time sharing our
ideas. The proceedings were a rich diet.
I went with an open mind, found substance and no negatives at all. We
will both admit to not being the most polished of academics. He is an
all-right guy based on what I have experienced, entirely proper,
courteous, well-spoken, and full of stories to tell.
We differ perhaps in one respect, maybe we don't: Complain about what he
is and does in the light that he was in reality created by the government
itself.....it's their fault, including some words of bitterness as well. I
seemed to have materialized out of thin air, so to speak; that is an
illusion as I came also, be it obscure, inside track. We agree about the
contempt that we have for some things, expressing it somewhat differently.
Cryptography has become a field of specialists with work in a few chosen
different areas. That describes both of us. So many are unwilling to
take the burden of doing new and isolated work; I guess newbees expect
somebody to hold their hand all the time.
Never be afraid to say what if, to reach through your own failings to
greater goals, and, as I have done so recently, be ready to walk, such as
it is, when some had said you would not do so again. If you think you can
dismiss us, you dismiss in kind your chance to have your own unfettered
creative opportunities.
--
When the horse dies, get off.
------------------------------
** 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
******************************
