---------- Forwarded message ----------
Date: Wed, 19 Sep 2001 13:50:53 -0700
From: John Gilmore
To: Pawel Krawczyk
Cc: Bram Cohen , cryptography@wasabisystems.com,
gnu@toad.com, tytso@mit.edu
Subject: Re: chip-level randomness?
The real-RNG in the Intel chip generates something like 75 kbits/sec
of processed random bits. These are merely wasted if nobody reads them
before it generates 75kbits more in the next second.
I suggest that if application programs don't read all of these bits
out of /dev/intel-rng (or whatever it's called), and the kernel
/dev/random pool isn't fully charged with entropy, then the real-RNG
driver should feed some of the excess random bits into the /dev/random
pool periodically. When and how it siphons off bits from the RNG is a
separate issue; but can we agree that feeding otherwise-wasted bits
into a depleted /dev/random would be a good idea?
A better way to structure this might be for /dev/intel-rng to register
with /dev/random as a source of entropy that /dev/random can call upon
if it depletes its pool. /dev/random would then be making decisions
about when to stir more entropy into the pool (either in response to a
read on /dev/random, or to "read ahead" to increase the available pool
in between such reads). Thus, when demand on /dev/random is high, it
would become one of the "application programs" that would compete to
read from /dev/intel-rng. Since /dev/random is the defined interface
for arbitrary applications to get unpredictable bits out of the
kernel, I would expect that in general, /dev/random is likely to be
the MAJOR consumer of /dev/intel-rng bits.
(Linux IPSEC uses /dev/random or /dev/urandom for keying material. It
can easily consume many thousands of random bits per second in doing
IKE's Diffie-Hellman to set up dozens of tunnels. Today this "surge
demand" occurs at boot time when setting up preconfigured tunnels -- a
particularly bad time since the system hasn't been collecting entropy
for very long. /dev/intel-rng's high-spead stream can significantly
improve the quality of this keying material, by replenishing the entropy
pool almost as fast IPSEC consumes it. Over time, IPSEC's
long-term demand for random bits will increase, since opportunistic
encryption allows many more tunnels to be created, with much less
effort per tunnel by the system administrator.)
Also, the PRNG in /dev/random and /dev/urandom may someday be broken
by analytical techniques. The more diverse sources of true or
apparent randomness that we can feed into it, the less likely it is
that a successful theoretical attack on the PRNG will be practically
successful. If even a single entropy source of sufficiently high
speed is feeding it, even a compromised PRNG may well be unbreakable.
John
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com
