Date: Sun, 23 Jul 2000 14:59:28 -0400 From: "Jeroen C. van Gelderen" <jeroen@vangelderen.org> To: Kris Kennaway <kris@FreeBSD.ORG> Cc: Mark Murray <mark@grondar.za>, current@FreeBSD.ORG Subject: Re: randomdev entropy gathering is really weak Message-ID: <397B4090.6A15442E@vangelderen.org> References: <Pine.BSF.4.21.0007230346320.94748-100000@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Kris Kennaway wrote:
>
> 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.
Why not?
> 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.
You would block until the pool is filled with entropy.
[...]
> 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).
Fortunately you don't need them :-)
> > 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.
And you can make Yarrow do just that. Not very practical but
you can do it. You effectively set Pg to 1/(2^(k/3)).
> > 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).
Reseeds do not *have* to happen asynchronously as pointed out
above. What is of importance is that you *cannot* forcibly
trigger a reseed without there being enough entropy in the
pools. There is nothing against having /dev/random block
until the pools have accumulated enough entropy.
Cheers,
Jeroen
--
Jeroen C. van Gelderen o _ _ _
jeroen@vangelderen.org _o /\_ _ \\o (_)\__/o (_)
_< \_ _>(_) (_)/<_ \_| \ _|/' \/
(_)>(_) (_) (_) (_) (_)' _\o_
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?397B4090.6A15442E>