This result would seem to raise questions about SHA1 and MD5 as much as about the quality of /dev/random and /dev/urandom. Naively, it should be difficult to create input to these hash functions that cause their output to fail any statistical test.
Arnold Reinhold At 3:23 PM -0500 1/15/02, Thor Lancelot Simon wrote: >Many operating systems use "Linux-style" (environmental noise >stirred with a hash function) generators to provide "random" >and pseudorandom data on /dev/random and /dev/urandom >respectively. A few modify the general Linux design by adding an >output buffer which is not stirred so that bits which have already >been output are not stirred into the pool of "new" "random" data >(IMO, not doing this is insane, but that's a different subject). > >The enclosed implementation of the FIPS140-1/2 statistical test >appears to show that such generators fail the "runs" test quite >regularly. Interestingly, the Linux generator seems to do better >the longer you let it run (which, perhaps, suggests that quite a >bit of data should be run through it at boot time and discarded) >but other, related generators do not. > >The usual failure mode is "too many runs of 1 1s". Using MD5 >instead of SHA1 as the mixing function, the Linux generator >also displays "too many runs of 1 0s". I have not yet seen >other failure modes from these generators. > >To reproduce my results, just compile the enclosed and do >"a.out < /dev/urandom" on your platform of choice. > >Thor > >Attachment converted: Arnold's iMac:fips140.c (TEXT/ttxt) (0011EDDD) --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]