Cryptography-Digest Digest #723, Volume #10 Sat, 11 Dec 99 12:13:01 EST
Contents:
Re: New RNG Technique ("Trevor Jackson, III")
Re: New RNG Technique (Pelle Evensen)
Re: Scott's Screaming Security Method (Tom St Denis)
some questions about DES ("Buchinger Reinhold")
Re: Quantum Computers and Weather Forecasting ("Phil & Jean Bergerot")
Re: Questions about message digest functions (SCOTT19U.ZIP_GUY)
Re: Questions about message digest functions (lordcow77)
Re: New RNG Technique (Tim Tyler)
----------------------------------------------------------------------------
Date: Sat, 11 Dec 1999 10:58:43 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: New RNG Technique
Steve Harris wrote:
> 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.
That's a tall one. How did you figure this out?
> 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: Pelle Evensen <[EMAIL PROTECTED]>
Subject: Re: New RNG Technique
Date: Sat, 11 Dec 1999 16:57:35 +0100
Steve Harris ([EMAIL PROTECTED]) wrote:
[snip]
: 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.
Suggested reading;
http://www.counterpane.com/pseudorandom_number.html
http://www.counterpane.com/yarrow-notes.html
Cheers,
Pell
--
Pelle Evensen, [EMAIL PROTECTED] Telenordia AB/Algonet
http://www.evensen.org/pgp.html for public key.
PGP fingerprint 22 DC 52 0D 7E 00 F7 9C 8B EB F0 55 1E 8C 71 5E
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: comp.compression,alt.security
Subject: Re: Scott's Screaming Security Method
Date: Sat, 11 Dec 1999 15:57:52 GMT
In article <82to4b$2l6q$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> I know most of you will never have access to good ciphers. The
> NSA and crypto gods will see to that. But it does not mean that
> you can't use some of the weak AES methods and still obtain a
> far higher degree of security than what they want. Below is a
> procedure that is "not all or nothing" but would allow one to
> encrypt by removing the so called error recovery "feature"
> that most people are stuck using.
> Here it is in a nutshell You need 3 ciphers and 2 one to one
> compressions to achieve the results. IF you have access to the
> routines them selves it can be done in one pass since each method
> works on the data previously processed but I will explain it as 5
passes.
>
> Pass one Encrypt with AES using weak 3 letter chaining even ECB
> Pass two use Compression A "explained latter"
> Pass three Encrypt with different key (with different method if one
wishes}
> Pass four use Compression B
> Pass five Encrypt with different key
>
> For the truely insecure among you. You can make this "all or nothing"
by
> reversing the byte order in the file after each compression. But that
requires
> whole file at one time..
>
> Know for a disccusion of how to implement the Compression.
> by Compression A I mean one of my one to one compressions that
> uses a "condition file" with all 256 possible characters. This makes
> a starting tree that can be greatly varied. But since compression is
> one to one no information is added to data stream. Also the message
> will as it passes through the compression will change in length so
that
> it is highly unlikely that one can know where a block from the
previous
> encryption layer is passed to next encryption layer and it is highly
unlikely
> to even be the same length. For Compression B you use a different
> "condition file" with all the 256 possible characters in the file.
>
> The input file should be at least long enogh for a few blocks to be
> encrypted or you can reject the file as to short. Notice also that
> each compression will most likely make the file longer and that
> the encryption methods should handle short blocks at the end of files.
> Most methods already have a way to do this but if at least one block
> is encrypted on each pass you can just pass the short block without
> doing anything to it. Since the state of the adapative huffman
compressor will
> be such that the data in last block will be transformed by the
compression.
>
> Any thoughts on this by my nonadmirers.
It's probably perfectly [or pratically] secure, just 100% inefficient.
So is encrypting solely with 2048 bit RSA but we don't do that either.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Buchinger Reinhold" <[EMAIL PROTECTED]>
Subject: some questions about DES
Date: Thu, 9 Dec 1999 12:33:29 +0100
Hi !
I write a paper about DES for my school - leaving exam and I need some
further informations.
Where was and is DES used ?
Has DES been verified in 1998 ?
If not what's its succession ?
How fast and with which computer (price) can DES been broken nowadays ?
If you have some references (websites, ...) for your knowledge please let me
know !
I am VERY grateful for you help !
Reinhold Buchinger
------------------------------
From: "Phil & Jean Bergerot" <[EMAIL PROTECTED]>
Crossposted-To: sci.physics,sci.geo.meteorology
Subject: Re: Quantum Computers and Weather Forecasting
Date: Fri, 10 Dec 1999 21:11:12 -0800
Hey, maybe you would appreciate my favorite response to the question "What's
happening?" . . . A gerund.
Definitely off subject.
-Jean
Richard Herring <[EMAIL PROTECTED]> wrote in message
news:82j3nr$5k4$[EMAIL PROTECTED]...
In article <[EMAIL PROTECTED]>, Joseph Bartlo
([EMAIL PROTECTED]) wrote:
> Richard Herring wrote:
> > There appeared to be some implicit bragging about your punctuation :-)
> > But I think you meant at, not @.
> Actually I meant @, similarly I quasi-comically imitated John's use of
> <at> for @ in his e-mail address.
Aha. Understood.
> Here is how I use @ & at (not stating this is grammatically correct, only
> logical for me) :
Fair enough.
> A shower occurred @ 4 PM at Tannersville.
> "at" referring to a specific *place*, @ referring to another type of
> reference, such as a time; which you cannot be "at". Thus :
In conservative English usage @ is called the "commercial at" symbol,
suggesting that it should only be used for prices and the like:
3 gadgets @ $5 each: $15
> I won't interfere with your attempt @ minimizing your accomplishments...
Wow, a gerund. Not many people know how to use those any more.
> Perhaps "attempt of minimizing" is best ?
Definitely not.
But "attempt to <verb>", "attempt at <gerund>", "attempt on <noun>"
would all be legitimate in appropriate contexts.
--
Richard Herring | <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Questions about message digest functions
Date: Sat, 11 Dec 1999 17:30:04 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>Paul Rubin <[EMAIL PROTECTED]> wrote:
>: In article <[EMAIL PROTECTED]>, Jim Gillogly <[EMAIL PROTECTED]> wrote:
>:>Pelle Evensen wrote:
>
>:>> Have there been any papers published on
>:>> 1a) Whether SHA-1 is a permutation for a message the same length as the
>:>> digest-length (160 bits)?
>:>
>:>Not in a refereed journal. It's obviously a bad flaw: if it were true,
>:>then the attacker seeing a hash of a 160-bit message that ended up all
>:>zeroes or ones would know exactly what message had been hashed.
>
>: I think Pelle is asking whether SHA-1 is a bijection, i.e. a
>: permutation on the 2^160 160-bit messages, not a permutation on
>: the bits in the message.
>
>Indeed.
>
>: The answer is still, it's almost certainly not a bijection.
>: Why on earth would anyone expect it to be one?
>
>It appears to be a desirable property.
>
>Part of the point of hashes is to avoid hash collisions. A permutation
>would avoid collisions to the maximum possible extent.
>Nothing else would do this for the case where message size = hash size.
Tim you should realize that while it is obvious that if one is hashing a
message the same size as the hash size it should be bijective. Most
people here do not understand why this is a highly desirable feature.
But you have to forgive them since they are the product of a society
where the art of encryption is to be kept from the public and the
governement program of dumbing people down is achieving great
success.
For the ignorant if you hash a message of the same size and
it is not bijective then certains patterns of the hash will be impossibe
to achieve so if the hash used for a key certain keys can be eliminated
from the solution space. Also patterns that can be hashed to by more
than one input could be checked first.
What one should do when one needs hashing to to hash a message
that is larger than the hash size and the "reverseibility" problem goes
away.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: lordcow77 <[EMAIL PROTECTED]>
Subject: Re: Questions about message digest functions
Date: Sat, 11 Dec 1999 08:46:15 -0800
In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]> wrote:
> wtshaw <[EMAIL PROTECTED]> wrote:
> : In article <[EMAIL PROTECTED]>, Pelle Evensen
> <[EMAIL PROTECTED]> wrote:
> :> Have there been any papers published on
> :> 1a) Whether SHA-1 is a permutation for a message the same
> length as the
> :> digest-length (160 bits)? [snip]
> :> 1c) Is this true (or can it be true) for any other, supposedly
> secure,
> :> one-way, collision resistant, hash-functions?
> : 1c holds a host of sins of presumption.
> Another wtshaw cryptic comment ;-)
> What is the answer to 1c?
> Is it true? Tim does not know for certain, but thinks the answer
> is
> "yes":
> Hash functions may be made from block cyphers. Block cyphers are
> reversible. Consequently, a message hash of a message with the
> hash
> size, the block size and the message size all equal will be a
> bijection.
> *Can* it be true? *Definitely* "yes".
Idiot. The construction that transforms a block cipher cryptographic
primative into a hash function should destroy the bijectiveness of the
block cipher. A hash function should be indistinguishble from a random
function, not random permutation. A random function should have images
that cannot be reached from preimages of the same length as the image.
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: New RNG Technique
Reply-To: [EMAIL PROTECTED]
Date: Sat, 11 Dec 1999 17:01:01 GMT
Steve Harris <[EMAIL PROTECTED]> wrote:
: 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 has the following important features:
: 2.) The output is not correlated to the seed.
<cough>
: 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.
A highly *undersirable* characteristic for many uses.
: 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.
<cough>
: 8.) ECHO does not repeat, it has a period of infinity.
This is impossible, for any deterministic system with finite storage.
I believe you require the user to enter genuinely random new values
periodically to make this claim true. As this is the case, I'm suprised
you draw attention to this as a "feature".
: 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.
<cough>
[snip]
: It has the following security features:
: 1.) Large seed length.
: 2.) No input attack is possible with a manually entered seed.
<cough>
: 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. [...]
<cough>
Your security claims are ridiculous :-(
: 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 tha
: this produces a bit stream good enough to pass any test for randomness.
Nope. Take every 4096 elements. Count the frequency of 0s. It will be
a constant value - the same each time you perform the test. No genuinely
random stream would exhibit this property. Your program fails
immediately, on an extremely simple test :-(
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Murphy was an optimist.
------------------------------
** 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
******************************
