Question

I have been reading about /dev/urandom, and as far as I can tell, /dev/random creates cryptographically random numbers by taking advantage of several events like network packet timings, etc. However, did I understand right that /dev/urandom uses a PRNG, seeded with a number from /dev/random? Or does it just use /dev/random as long as there are bits — and when they run out it falls back to some PRNG with a seed gathered from where?

Answer 1

From the urandom manpage:

The random number generator gathers
environmental noise from device
drivers and other sources into an
entropy pool. The generator also
keeps an estimate of the number of
bits of noise in the entropy pool.
From this entropy pool random numbers
are created.

When read, the /dev/random device
will only return random bytes within
the estimated number of bits of noise
in the entropy pool. /dev/random
should be suitable for uses that need
very high quality randomness such
as one-time pad or key
generation. When the entropy pool
is empty, reads from /dev/random will
block until additional environmental
noise is gathered.

A read from the /dev/urandom device will not block waiting for more
entropy. As a result, if there is
not sufficient entropy in the entropy
pool, the returned values are
theoretically vulnerable to a
cryptographic attack on the algorithms
used by the driver. Knowledge of how
to do this is not available in the
current unclassified literature, but
it is theoretically possible that such
an attack may exist. If this is a
concern in your application, use
/dev/random instead.

both uses a PRNG, though using environmental data and entropy pool makes it astronomically much more difficult to crack the PRNG, and impossible without also gathering the exact same environmental data.

As a rule of thumb, without specialized expensive hardware that gathers data from, say, quantum events, there is no such thing as true random number generator (i.e. a RNG that generates truly unpredictable number); though for cryptographic purpose, /dev/random or /dev/urandom will suffice (the method used is for a CPRNG, cryptographic pseudo-random number generator).

The entropy pool and blocking read of /dev/random is used as a safe-guard to ensure the impossibility of predicting the random number; if, for example, an attacker exhausted the entropy pool of a system, it is possible, though highly unlikely with today’s technology, that he can predict the output of /dev/urandom which hasn’t been reseeded for a long time (though doing that would also require the attacker to exhaust the system’s ability to collect more entropies, which is also astronomically improbably).