There was an error in the bounds for the runs test specified by NIST; last
october they updated FIPS 140-2 to specify new bounds. An updated version
of my code can be found at http://people.qualcomm.com/ggr/QC/ (our old web
pages are stale, and I'm still trying to have them taken down by our
Thor Lancelot Simon says:
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
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,
At 03:23 PM 1/15/2002 -0500, 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
Arnold G. Reinhold says:
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.
I would think
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
