From owner-freebsd-questions@FreeBSD.ORG Mon Sep 17 02:24:27 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 E4ABF16A417 for ; Mon, 17 Sep 2007 02:24:27 +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 A303113C442 for ; Mon, 17 Sep 2007 02:24:27 +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 8D7295193B for ; Sun, 16 Sep 2007 22:24:24 -0400 (EDT) Date: Mon, 17 Sep 2007 03:24:22 +0100 From: RW To: freebsd-questions@freebsd.org Message-ID: <20070917032422.33361b0a@gumby.homeunix.com.> In-Reply-To: <200709162351.58692.fbsd.questions@rachie.is-a-geek.net> References: <20070913153630.GA9448@slackbox.xs4all.nl> <200709161521.39955.fbsd.questions@rachie.is-a-geek.net> <20070916215550.65e09a71@gumby.homeunix.com.> <200709162351.58692.fbsd.questions@rachie.is-a-geek.net> 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 02:24:28 -0000 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. This is just off the top of my head, but for example, say I want to create a data dvd that's encrypted with a unique keyfile. I may have a script that starts like this: # Create a dvd image file prefilled with random bits dd if=/dev/urandom of=./dvd bs=1m count=4480 # Create a random 512-bit keyfile dd if=/dev/random of=./keyfile bs=64 count=1 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. As things stand, Yarrow is secure, but it might not be a few years from now.