---------- Forwarded message ---------- Date: Wed, 19 Sep 2001 13:50:53 -0700 From: John Gilmore <gnu@toad.com> To: Pawel Krawczyk <kravietz@aba.krakow.pl> Cc: Bram Cohen <bram@gawth.com>, 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