From owner-freebsd-current Mon Jul 31 18: 4:28 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 14E0637B6ED; Mon, 31 Jul 2000 18:04:21 -0700 (PDT) (envelope-from jeroen@vangelderen.org) Received: from vangelderen.org (grolsch.ai [209.88.68.214]) by cypherpunks.ai (Postfix) with ESMTP id EC61149; Mon, 31 Jul 2000 21:04:17 -0400 (AST) Message-ID: <39862211.166FACF4@vangelderen.org> Date: Mon, 31 Jul 2000 21:04:17 -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: Mark Murray Cc: Brian Fundakowski Feldman , current@FreeBSD.ORG Subject: Re: randomdev entropy gathering is really weak References: <200007300918.LAA07595@grimreaper.grondar.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mark Murray wrote: > > > Mark already stated that in *practicality*, Yarrow-BF-cbc-256 1.0 > > (I guess that's the proper name for this :-) is complex enough and > > generates good enough ouput. If you /really/ want to make the attack > > on it much harder, how about this: if you're going to read 1024 bits > > of entropy from Yarrow on /dev/random, you will request it all at once > > and block just as the old random(4) used to block; the blocking can > > occur at 256 bit intervals and sleep until there is a reseed. Waiting > > to reseed for each read will ensure a much larger amount of "real" > > entropy than it "maybe" happening at random times. > > This is a reversion to the count-entropy-and-block model which I have > been fiercely resisting (and which argument I thought I had sucessfully > defended). You argued successfully against using the old PRNG mechanism but not against the blocking bit. What is your rationale for not doing the blocking when the client actually wants a guarantee that entropy is not being re-used? > My solution is to get the entropy gathering at a high enough rate that > this is not necessary. What if you cannot guarantee that (and you cannot guarantee that in practice)? > I also agreed to _maybe_ look at a re-engineer of the "old" code in a > secure way if a decent algorithm could be found (I am reading some > papers about this ATM). Why would you if you can provide blocking with Yarrow? 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