From owner-freebsd-current Sun Jul 23 4:31:56 2000 Delivered-To: freebsd-current@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 5683C37B74A; Sun, 23 Jul 2000 04:31:54 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id EAA02369; Sun, 23 Jul 2000 04:31:54 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Sun, 23 Jul 2000 04:31:54 -0700 (PDT) From: Kris Kennaway To: Mark Murray Cc: current@FreeBSD.org Subject: Re: randomdev entropy gathering is really weak In-Reply-To: <200007231010.MAA00467@grimreaper.grondar.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message