The perils of security tools

The Fungi fungi at
Tue May 27 18:14:22 EDT 2008

On Tue, May 27, 2008 at 12:29:11PM -0600, Chad Perrin wrote:
> My understanding of the situation is that the way you get secure
> use of a PRNG is by feeding it "real" entropy,
> the reason /dev/random is cryptographically secure is that it
> *does* require "real" entropy, which of course means that it slows
> down a lot when you run out of "real" entropy in the pool.

This statement seems a little confused. If you 'man 4 random' on a
Linux system, you will see:

   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

So /dev/random on Linux isn't so much a PRNG seeded by entropy, as a
direct means of pulling (hashed) entropy directly out of the pool.
For each byte of /dev/random you read, the entropy pool is depleted
by the same amount. When there are no estimated bits of entropy
remaining, further reads are blocked until new entropy is available
(it doesn't just "slow down a lot"). Since /dev/random use depletes
the pool directly, it is imperative that wasteful reads of this
pseudo-device be avoided at all costs. By contrast, /dev/urandom
*is* a PRNG (optionally) seeded by available entropy. If its seed
value is known, output sequence can be determined until it gets

> An additional entropy pool would need more places to *get*
> entropy, of course.

For the sake of this discussion, "the entropy pool" should be
defined as a pool of all entropy sources available to the system.
Thus, the idea of "an additional entropy pool" wouldn't make any
sense, though "additional sources of entropy feeding/mixed into the
entropy pool" might be what you were getting at (such as a hardware
RNG chip, webcam pointed at a few lava lamps, microphone aimed at
the nearest freeway, et cetera).

> Essentially, giving the characteristics of cryptographically
> useful randomness and perfect forward secrecy to /dev/urandom
> would ultimately mean you turned it into a duplicate of
> /dev/random.

Well, /dev/urandom (on Linux) represents a PRNG while /dev/random
does not. I suppose if you read from /dev/urandom byte-at-a-time and
reseed it with a byte from /dev/random between each read, it will
essentially be (deterministically because you know how to predict
the mapping between seed and sequence number n) a duplicate of
/dev/random, but this argument is superfluous.
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP(fungi at; IRC(fungi at; ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fungi at;
MUD(fungi at; WWW(; }

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at

More information about the cryptography mailing list