From owner-freebsd-questions@FreeBSD.ORG Mon Sep 17 13:37:13 2007 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0085216A4D4 for ; Mon, 17 Sep 2007 13:37:13 +0000 (UTC) (envelope-from fbsd06@mlists.homeunix.com) Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by mx1.freebsd.org (Postfix) with ESMTP id 949AC13C442 for ; Mon, 17 Sep 2007 13:37:12 +0000 (UTC) (envelope-from fbsd06@mlists.homeunix.com) Received: from gumby.homeunix.com. (unknown [87.81.140.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id F03035197C for ; Mon, 17 Sep 2007 09:37:01 -0400 (EDT) Date: Mon, 17 Sep 2007 14:36:59 +0100 From: RW To: freebsd-questions@freebsd.org Message-ID: <20070917143659.5a198772@gumby.homeunix.com.> In-Reply-To: References: <20070917032422.33361b0a@gumby.homeunix.com.> X-Mailer: Claws Mail 3.0.0 (GTK+ 2.10.14; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: /dev/random question X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2007 13:37:13 -0000 On Mon, 17 Sep 2007 03:10:30 -0700 "Ted Mittelstaedt" wrote: > > > > -----Original Message----- > > From: owner-freebsd-questions@freebsd.org > > [mailto:owner-freebsd-questions@freebsd.org]On Behalf Of RW > > Sent: Sunday, September 16, 2007 7:24 PM > > To: freebsd-questions@freebsd.org > > Subject: Re: /dev/random question > > > > > > On Sun, 16 Sep 2007 23:51:56 +0200 > > Mel wrote: > > > > > On Sunday 16 September 2007 22:55:50 RW wrote: > > > > On Sun, 16 Sep 2007 15:21:38 +0200 > > > > > An applicatation using /dev/random doesn't see the difference. It > > > was necessary at the time, because systems couldn't produce enough > > > entropy, so they could put the application on hold till more was > > > available. All the application wants is randomness and it accounts > > > for the fact that it can be blocked, yet it never gets blocked so > > > it's happy(tm) either way. > > > > > > Also, I can't see how you can usefully improve on /dev/random > > > other then getting rid of the blocking, so applications don't > > > have to account for it. > > > > > > > Using Yarrow for /dev/random is not an intrinsically bad idea, > > > > but it is controversial. > > > > > > Removing /dev/random all together would be controversial. This is > > > just backwards compatibility. Nothing changed as far as a consumer > > > of /dev/random is concerned. > > > > It's not about interfaces or performance - it's about security. > > > > The difference is that Yarrow is a PRNG that reuses the same 160 > > bits of entropy until it reseeds itself. A traditional /dev/random > > will output fewer random bits than it get in as interrupt entropy > > (a good implementation will be conservative about this). A lot of > > people prefer the latter approach for critical things like key > > generation. > > > > Understood but this was already known by the authors of the > FreeBSD /dev/random device. > > If the system is running on the software generator (yarrow) the > generator is reseeded from entropy gathered from the system. The > lan, serial, hardware and software interrupts in the system all > supply entropy. If for some reason the PRNG cannot gather enough > entropy fast enough to reseed then the status of the sysctrl > > kern.random.sys.seeded > > changes from 1 to 0 and the /dev/random device will start blocking > until entropy allows a reseed OR a process with superuser privileges > writes something to the random device which will be used for reseed. > This is documented in the man page. You didn't read it carefully enough (although the page isn't very clear). Yarrow starts-off blocked; when it's accumulated a certain amount of entropy (usually from the entropy file) it unblocks and "kern.random.sys.seeded" switches from 0 to 1. It will *never* switch back to zero of its own accord. What the man page is saying is that if you set "kern.random.sys.seeded=0" the device will return to the initialization state where it waits for enough entropy to unblock again. > Now I hear you saying "Ah ha - so the FreeBSD random device does > block after all" Well, yes and no. In most random devices under > UNIX they are very slow. So it is easy for the system to overrun > the random device. But Yarrow is fast enough so that the question > of blocking becomes theoretical, not practical. I've run randomness > test programs on a number of FreeBSD systems with the Yarrow-based > driver that were doing nothing else and the device has never > blocked. This is based on the misconception that Yarrow will block when it runs short of entropy - it doesn't, it simply reuses it indefinitely. > ... > > ... > > With FreeBSD 6.2 both files will be filled by Yarrow and it's likely > > that the end of ./dvd and the whole of ./keyfile will come from the > > same Yarrow pseudo-random sequence. If enough of the random data > > survives at the end of the dvd it may allow an attack against the > > PRNG. > > > > No, it wouldn't. The PRNG attacks are dependent on the PRNG being > bad enough that the algorithim favors certain groups of numbers > regardless of the seed being fed to it. > ... > > As things stand, Yarrow is secure, but it might not be a few years > > from now. > > > > That's true for all encryption assuming computing power continues to > grow by leaps and bounds. My point was that Yarrow may have weaknesses that we don't yet understand.