Re: insufficient entropy for rnd
Daniel Carosone <[email protected]>
| Newsgroups | gmane.os.netbsd.devel.crypto |
|---|---|
| Message-ID | <[email protected]> |
On Thu, Aug 21, 2003 at 11:19:35AM -0400, Michael Richardson wrote: > > Daniel> pointed at lava lamps, fish tanks, busy streets, etc. - various > Daniel> hobby or commercial rng devices (diode noise, etc) > > Check out: > http://www.av8n.com/turbid/ Nice paper. The arguments in this paper strongly support the model used by our rnd(4) device, granting the requirement that it has to keep a seed pool around. In particular, that any amount of noise, from any source, fed into the pool will help, while no amount of predictable input will harm. Which steal leaves us looking for sources of noise on some systems, which is where he starts getting into using the audio device (and not keeping any input state, which is a nice safety net). > Daniel> Most of these measures are basically unnecessary if you have one > Daniel> of the newer i386 motherboards with hardware RNG, and for most > > If you speak about Intel's RNG's, then it is my understanding that it is > impossible to prove that this source isn't biased, since the bit stream has > already been whitened. "Trust us" says Intel. As above, it just doesn't matter for our usage. We don't use data from the rng directly - it just gets stirred into the pool along with everything else. As long as it has any amount of unpredictability (and it should be much better than that), it helps. As long as it arrives asynchronously with reads from rnd(4) that might start revealing information about the internal state, the feasibility of any attack against the data is very low. Strictly speaking, even if (unrelated) interrupts arrive asyncronously with such reads, they help, because timing information is fed back into the pool on reads. So, without complete knowledge of the pool you can't learn complete knowledge of the pool (and even with you'll soon lose that knowledge as new stuff is fed in). -- Dan.