From owner-freebsd-current Mon Jul 24 18:51:31 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 0DAC237B875; Mon, 24 Jul 2000 18:51:24 -0700 (PDT) (envelope-from jeroen@vangelderen.org) Received: from vangelderen.org (grolsch.ai [209.88.68.214]) by cypherpunks.ai (Postfix) with ESMTP id E75DD49; Mon, 24 Jul 2000 21:51:21 -0400 (AST) Message-ID: <397CF299.9F89E1CA@vangelderen.org> Date: Mon, 24 Jul 2000 21:51:21 -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: Kris Kennaway , current@FreeBSD.ORG Subject: Re: randomdev entropy gathering is really weak References: <200007240603.IAA03449@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: [...] > > > 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. This is not correct for a variety of reasons. But that's all fairly theoretical and ... not relevant for the discussion at hand. > > What I meant with that point is that the user may get, say an extra few > > hundred bits out of it with no new entropy before the scheduled reseed > > task kicks in. > > How does he know which bits are which? His analysis task just got a whole > lot more difficult. Again, not entirely correct but not relevant either... Kris is simply right in that the /dev/random semantics change and that more bits can be output by Yarrow than there is entropy gathered. *In theory* the complexity of an attack on our Yarrow has an upper bound of 2^256 and *in theory* this is less than the complexity of an attack on our current /dev/random. This is a hard fact, no way around that. However, the big question here is not about theory but about *practicality*. Is Yarrow less secure than /dev/random in practice? How does our /dev/random hold up under attack? How does Yarrow compare? I think we need to evaluate these practical questions instead of deep theoretical issues as Yarrow is all about practicality. At a more fundamental level we will need to answer the question: "Do we need to preserve the current /dev/random semantics or can we decide to change 'em? [1]". And how will this affect our applications *in practice*. So let's concentrate this discussion on the practical issues and explain why you think backing /dev/random with Yarrow and changing the semantics is justifyable or even a good thing. Cheers, Jeroen [1] And, should we decide not to change /dev/random semantics, can we still back /dev/random with a modified Yarrow? -- 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