[tlug] /dev/random is truly random?

["Stephen J. Turnbull" <stephen@??>]

Nguyen Vu Hung writes:

 > The term hard is confusing and doesn't have any metrics.

 > * How "hard" it is to predict the randomness of /dev/random ?

Essentially impossible for non-realtime applications.  /dev/random
collects an entropy pool from the physical world.  If it doesn't have
enough entropy, it will refuse to give you random bits until it does.
This implies a DoS attack, by requesting random numbers from
/dev/random until it runs out of entropy.

/dev/urandom will fall back on a pseudo-random number generator, but
presumably the seed is very hard to predict.

 > * Is there any way to choose a seed other than the system timer ?

Read the code.  Probably not, and it probably doesn't matter, because
the seed is something like nanoseconds % 1000, I would bet.

 > * Any example run ( or papers ) out there on how to predict the
 > randomnese of /dev/random ( or the randomese of ( computer
 > generated ) random number ?

/dev/random may or may not be random (cf. the Improbability Drive from
The Hitchhiker's Guide to the Galaxy).  However, it is essentially
unpredictable (it's a true one-time pad), with the important exception
of the DoS attack I described.

For pseudo-random numbers, start with Donald Knuth, _The Art of
Computer Programming_, vol. 1 (Fundamental Algorithms).  That was
written about 30 years ago, but it will keep you busy for a while. ;-)
I can do the math for Knuth, it's elementary (but not easy).

A shorter, but very hard, path to enlightenment would be to start at
the Rc4 article on Wikipedia.  ARC4 is a very well-known, high-quality
stream cipher, although it seems that it is not currently considered
sufficiently secure for wireless networks (thus the deprecation of
WEP).  I can't hack the math in most of the papers cited here.