From owner-freebsd-current Sun Jul 23 11:59:35 2000 Delivered-To: freebsd-current@freebsd.org Received: from cypherpunks.ai (cypherpunks.ai [209.88.68.47]) by hub.freebsd.org (Postfix) with ESMTP id 909EE37B6C8; Sun, 23 Jul 2000 11:59:31 -0700 (PDT) (envelope-from jeroen@vangelderen.org) Received: from vangelderen.org (grolsch.ai [209.88.68.214]) by cypherpunks.ai (Postfix) with ESMTP id EB74257; Sun, 23 Jul 2000 14:59:28 -0400 (AST) Message-ID: <397B4090.6A15442E@vangelderen.org> Date: Sun, 23 Jul 2000 14:59:28 -0400 From: "Jeroen C. van Gelderen" X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Kris Kennaway Cc: Mark Murray , current@FreeBSD.ORG Subject: Re: randomdev entropy gathering is really weak References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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