Date: Sun, 23 Jul 2000 14:01:33 +0200 From: Mark Murray <mark@grondar.za> To: Kris Kennaway <kris@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: randomdev entropy gathering is really weak Message-ID: <200007231201.OAA00883@grimreaper.grondar.za> In-Reply-To: <Pine.BSF.4.21.0007230346320.94748-100000@freefall.freebsd.org> ; from Kris Kennaway <kris@FreeBSD.org> "Sun, 23 Jul 2000 04:31:54 MST." References: <Pine.BSF.4.21.0007230346320.94748-100000@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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). Do you have copies of the articles concerned? I'd surely appreciate a photocopy of the relevant pages if you don't mind! :-) > > 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. Hmm. Timing attacks? Known-input attacks? > > 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 :-( The dd if=/dev/urandom of=/dev/null is _already_ a doozy of a dos. Likewise a fork-bomb, a /tmp-filler, likewise a whole bunch of things much worse. Heck, you can hurt your system with cat /dev/zero > /dev/null. Asynchonous reseeding _improves_ the situation; the attacker cannot force it to any degree of accuracy, and if he has the odds stacked heavily against him that each 256-bits of output will have an associated reseed, it makes his job pretty damn difficult. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org 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?200007231201.OAA00883>