On Nov 9, 10:51am, Jason wrote:

> Kevin Buettner wrote:
> > If you read the code which implements /dev/random, you'll see that it
> > does use timings (I'm not sure if keyboard keypresses are considered
> > or not) from various of your computer's I/O subsystems in order to
> > generate its entropy pool.  The numbers that you get out of
> > /dev/random are pretty good random numbers so long as you do not ask
> > for them too fast.  (If you use up the entropy in the entropy pool too
> > quickly, it falls back on pseudo-random techniques for a while...)
> 
> cat /dev/random
> 
> spits out randomness at a medium pace. Also makes it pretty clear that
> keystrokes (or the interupts they generate) are definitly part of the
> package. Im not sure how one can use this up too fast, it seems to me
> that cat would use them up as fast as possible, and result in a
> constant stream of pseudorandom garbage if the above were true.

I was basing my remarks upon what I had read in the kernel sources. 
My remarks were not based on empirical evidence.  The last paragraph
from the following comment (found in drivers/char/random.c) is
pertinent...

 * Computers are very predictable devices.  Hence it is extremely hard
 * to produce truly random numbers on a computer --- as opposed to
 * pseudo-random numbers, which can easily generated by using a
 * algorithm.  Unfortunately, it is very easy for attackers to guess
 * the sequence of pseudo-random number generators, and for some
 * applications this is not acceptable.  So instead, we must try to
 * gather "environmental noise" from the computer's environment, which
 * must be hard for outside attackers to observe, and use that to
 * generate random numbers.  In a Unix environment, this is best done
 * from inside the kernel.
 * 
 * Sources of randomness from the environment include inter-keyboard
 * timings, inter-interrupt timings from some interrupts, and other
 * events which are both (a) non-deterministic and (b) hard for an
 * outside observer to measure.  Randomness from these sources are
 * added to an "entropy pool", which is mixed using a CRC-like function.
 * This is not cryptographically strong, but it is adequate assuming
 * the randomness is not chosen maliciously, and it is fast enough that
 * the overhead of doing it on every interrupt is very reasonable.
 * As random bytes are mixed into the entropy pool, the routines keep
 * an *estimate* of how many bits of randomness have been stored into
 * the random number generator's internal state.
 * 
 * When random bytes are desired, they are obtained by taking the SHA
 * hash of the contents of the "entropy pool".  The SHA hash avoids
 * exposing the internal state of the entropy pool.  It is believed to
 * be computationally infeasible to derive any useful information
 * about the input of SHA from its output.  Even if it is possible to
 * analyze SHA in some clever way, as long as the amount of data
 * returned from the generator is less than the inherent entropy in
 * the pool, the output data is totally unpredictable.  For this
 * reason, the routine decreases its internal estimate of how many
 * bits of "true randomness" are contained in the entropy pool as it
 * outputs random numbers.
 * 
 * If this estimate goes to zero, the routine can still generate
 * random numbers; however, an attacker may (at least in theory) be
 * able to infer the future output of the generator from prior
 * outputs.  This requires successful cryptanalysis of SHA, which is
 * not believed to be feasible, but there is a remote possibility.
 * Nonetheless, these numbers should be useful for the vast majority
 * of purposes.

I can only speculate that the reason for the slowness is that it
takes a while to compute the SHA hash.  (It's slow on my machine too.)

> according to /usr/src/linux/Documentation/devices.txt,
> /dev/random	Nondeterministic random number gen.
> /dev/urandom	Faster, less secure random number gen.
> 
> /dev/urandom is the one that spits out data endlessly when subjected
> to cat...
> 
> Perhaps the /dev/random in current distributions is really
> /dev/urandom? I cant say - I had to use mknod per the docs in the
> Linux source as there was no /dev/random on my system prior to me
> reading about it in a kernel upgrade (That means, BTW, that not only
> is relying on /dev/random not platform independant, but that it also
> will not function on older linux releases as well!)

To the best of my knowledge, no distribution aliases /dev/random
to /dev/urandom.  If they do, this is egregiously wrong since many
programs depend upon /dev/random to generate strong random numbers.