From owner-freebsd-current Fri Jul 21 21:26: 9 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 1B6A137B72F; Fri, 21 Jul 2000 21:26:07 -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 VAA91491; Fri, 21 Jul 2000 21:26:06 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Fri, 21 Jul 2000 21:26:06 -0700 (PDT) From: Kris Kennaway To: Mark Murray Cc: "Jeroen C. van Gelderen" , current@FreeBSD.ORG Subject: Re: randomdev entropy gathering is really weak In-Reply-To: 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 Fri, 21 Jul 2000, Kris Kennaway wrote: > > Section 2.1, last paragraph: > > "If a system is shut down, and restarted, it is desirable to store some > > high-entropy data (such as the key) in non-volatile memory. This allows > > the PRNG to be restarted in an unguessable state at the next restart. We > > call this data the reseed file." After rereading the paper in more detail, Step 7 of the reseed algorithm seems not entirely consistent with this: they explicitly refer to writing out "the next 2k bits of output from the generator to the seed file" (slightly different terminology, but I couldn't find any other references to the "seed file") Another important point is that Yarrow-160 is not useful for generating keys >160 bits, because of Shannon's theorem and the fact that it uses SHA-1. You seem to be using a blowfish-based hash function with 256-bit keysize (do you have a reference for using blowfish in that fashion?), but the point stands. It seems we would need to use an alternative interface which either synchronously reseeds with every output to generate stronger random data, or just taps into the (hashed) entropy pools directly. This was also a problem with our /dev/urandom (by design), but not with /dev/random since that tapped the entropy pool directly. Incidentally, it also looks like a problem with OpenBSD's /dev/arandom which is a stream cipher (arc4 with 256-bit key) periodically reseeded. 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