Date: Sun, 23 Jul 2000 04:31:54 -0700 (PDT) From: Kris Kennaway <kris@FreeBSD.org> To: Mark Murray <mark@grondar.za> Cc: current@FreeBSD.org Subject: Re: randomdev entropy gathering is really weak Message-ID: <Pine.BSF.4.21.0007230346320.94748-100000@freefall.freebsd.org> In-Reply-To: <200007231010.MAA00467@grimreaper.grondar.za>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 23 Jul 2000, Mark Murray wrote:
> > > > This design tradeoff is discussed in section 4.1 of the paper.
> > >
> > > Tweakable.
> >
> > Doing a reseed operation with every output is going to be *very*
> > computationally expensive.
>
> Tradeoff. What do you want? Lightning fast? Excessive security? Balance
> it out.
Thinking about it further, I dont think Yarrow can even do this (introduce
entropy into every output value) without bypassing the block cipher. And
if you reseed with every 256 bits of output then you're vulnerable to an
iterative guessing attack because the fast pool won't have much in it. So
if we want to use the Yarrow "backend" we'd have to basically reduce it to
the system I describe below.
> The acknowlegment that I am looking for is that the old, simple "gather
> entropy, stir with hash, serve" model is inadequate IMO, and I have not
> seen any alternatives.
There are two other models which rate "pretty well-designed" in the Yarrow
paper: the cryptlib and PGP PRNGs. I don't know what their properties are
right now (the cryptlib one is described in the paper on PRNG
cryptanalysis).
> I'll relent somewhat if a secure entropy distilling algorithm could be
> found; one which stands up to crypanalysis.
Well, a simple scheme which doesn't seem to suffer from any of the
vulnerabilities discussed in the schneier papers is to accumulate entropy
in a pool, and only return output when the pool is full. i.e. the PRNG
would either block or return 0 bytes of data, or a full pool's worth.
> Will you relent a step or two if I can get the entropy harvesting _rate_
> high enough? :-)
If we get the entropy pools filling fast enough that the reseed is
triggering close to every 256 bits of output then it becomes much less of
a concern (but it's still there, because reseeding happens asynchronously
with respect to PRNG output). However I think that in practice this will
be too heavy on the CPU (unless we weaken the reseed operation) and make
dd if=/dev/urandom of=/dev/null a very effective local user DoS :-(
Kris
--
In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <forsythe@alum.mit.edu>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0007230346320.94748-100000>