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>