From owner-freebsd-current Sun Jul 23 5: 1:37 2000 Delivered-To: freebsd-current@freebsd.org Received: from grimreaper.grondar.za (grimreaper.grondar.za [196.7.18.138]) by hub.freebsd.org (Postfix) with ESMTP id EDB0437B945; Sun, 23 Jul 2000 05:01:28 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grimreaper.grondar.za (localhost [127.0.0.1]) by grimreaper.grondar.za (8.9.3/8.9.3) with ESMTP id OAA00883; Sun, 23 Jul 2000 14:01:33 +0200 (SAST) (envelope-from mark@grimreaper.grondar.za) Message-Id: <200007231201.OAA00883@grimreaper.grondar.za> To: Kris Kennaway Cc: current@FreeBSD.org Subject: Re: randomdev entropy gathering is really weak References: In-Reply-To: ; from Kris Kennaway "Sun, 23 Jul 2000 04:31:54 MST." Date: Sun, 23 Jul 2000 14:01:33 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 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