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. ... > 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.
Last October in sci.crypt Greg Rose of Qualcomm reported: - Furthermore, on October 10, a change notice was - appended to the FIPS, to correct the false-alarm - rate of the the Runs Test. He went on to say: - I believe that the reason the tests were updated - was because the 1% error bound was too "loose". - Basically, with about 10 independent tests being - run, you could expect perfectly functional - hardware to fail the power-on checks about one - time in 20, for no good reason. The new bounds are - still pretty good at detecting true - non-randomness, particularly the kind that comes - from typical hardware problems, but with a much - smaller false-alarm rate. ... - BTW, I've updated my fips140.c program to the new, - correct, Runs Test values, and will send it to - people if they want it. Hopefully we will soon The internal date on the copy of Greg's fips140.c program that you included with this message is 2000, so I imagine you're using the old version. Have you tried his newer version, i.e. the one he believes reflects the current state of FIPS140? -- Jim Gillogly Hevensday, 25 Afteryule S.R. 2002, 01:03 12.19.8.16.5, 13 Chicchan 3 Muan, First Lord of Night --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]