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.
(text/plain)