Linux-style kernel PRNGs and the FIPS140-2 test

Arnold G. Reinhold reinhold at world.std.com
Tue Jan 15 17:52:01 EST 2002


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 majordomo at wasabisystems.com




More information about the cryptography mailing list