From owner-freebsd-current Mon Jul 24 12:50:34 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 7238B37BF09; Mon, 24 Jul 2000 12:50:28 -0700 (PDT) (envelope-from jeroen@vangelderen.org) Received: from vangelderen.org (grolsch.ai [209.88.68.214]) by cypherpunks.ai (Postfix) with ESMTP id 86AC849; Mon, 24 Jul 2000 15:50:10 -0400 (AST) Message-ID: <397C9DF2.18CBB7B3@vangelderen.org> Date: Mon, 24 Jul 2000 15:50:10 -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, Jeroen C. van Gelderen wrote: > > > > 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)). > > Oh, I missed this - thanks. It does introduce an extra overhead, namely > applying a generator gate with every output (since n < k and Pg < 1) and > then the full reseed with every k bits of output. I'm not too worried about that for three reasons: 1. The overhead will probably be insignificant. One doesn't use such vast amounts of random numbers. 2. At least the generator gate can be optimized out if it turns out to be a problem. 3. We could use a cipher with better key agility (CAST) to make each operation less computationally intensive. > ITYM Pg = k 2^(-k/3) > though - you want a maximum k bits of output, not 1. Pg is the number of blocks IIRC. > > Reseeds do not *have* to happen asynchronously as pointed out > > above. > > Yeah, but they do in the current implementation (AFAICT). Agreed. 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