From owner-freebsd-current Sun Jul 23 0:40:47 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 B8BD837C32B; Sun, 23 Jul 2000 00:40:44 -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 AAA82584; Sun, 23 Jul 2000 00:40:44 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Sun, 23 Jul 2000 00:40:44 -0700 (PDT) From: Kris Kennaway To: Mark Murray Cc: current@FreeBSD.org Subject: Re: randomdev entropy gathering is really weak In-Reply-To: <200007230727.JAA87605@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: > Your are missing the point that it is not possible to get more than > the ${number-of-bits-ofrandomness} from any accumulator or PRNG. You > have to draw the line somewhere; The current implementation has it > at 256. Uhh..a PRNG which hashes entropy samples with e.g. SHA1 and outputs the digest once the bucket is "full" will have 1-epsilon bit of entropy per 1 bit of output. It may not be very fast depending on the rate of entropy accumulation, but you can get as much entropy out of it as you want. This is basically the model I am advocating for /dev/random. It's also the alternative "basic design philosophy" described in the yarrow paper. > > If you want to generate a cryptographic key of length n bits then you > > really want >n bits of entropy in the random source you're deriving it > > from, otherwise your key is actually much weaker than advertised because > > it's easier for the attacker to attack the state of the PRNG that derived > > it than to attack the key itself. > > Aha! That is where Yarrow wins. The paper argues it much better than > me: Section 4.1, the paragraph that begins "Yarrow takes a different > approach...". See "important issue" number 2 on p6. Yarrow-derived numbers are only "good for" 256 bits of strength. Modulo reseeds, Yarrow never accumulates more than 256 bits of entropy. Therefore you are silly to use it for applications which require more than 256 bits of randomness. > Where do you draw the line? I could make it Yarrow-N, only to have > someone insist on $((N+1)) in the very next breath. Precisely, which is why /dev/random shouldn't use Yarrow, or any other seeded-cipher PRNG. > With what we have, I am staking my career on the "uncrackability" > of Blowfish-256. If that holds then Yarrow is safe. (The old one I'm not bothered about this. My point is that, by design, Yarrow is not suitable as a replacement for /dev/random (/dev/urandom, yes). 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