Subject: Re: insufficient entropy for rnd
To: Michael Richardson <email@example.com>
From: Daniel Carosone <firstname.lastname@example.org>
Date: 08/22/2003 11:22:52
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:
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).