Date: Mon, 17 Sep 2007 03:10:30 -0700 From: "Ted Mittelstaedt" <tedm@toybox.placo.com> To: "RW" <fbsd06@mlists.homeunix.com>, <freebsd-questions@freebsd.org> Subject: RE: /dev/random question Message-ID: <BMEDLGAENEKCJFGODFOCCEGJCAAA.tedm@toybox.placo.com> In-Reply-To: <20070917032422.33361b0a@gumby.homeunix.com.>
next in thread | previous in thread | raw e-mail | index | archive | help
> -----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 <fbsd.questions@rachie.is-a-geek.net> 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. 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. And the test program has indicated the non-randomness to be unmeasurably small. Now, maybe I had a slow CPU and a busy network. But a faster CPU would just generate entropy faster. And I would think that someone running the fastest FreeBSD system possible would be on a busy gigabit network, don't you? Lots of entropy there to feed the seed I think. > 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. > 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. In this instance you would look at the random bits at the end of the dvd that your encrypted data hadn't overwritten, observe the clumping, and that would vastly decrease the keyspace you would need to search on a brute force attack on the key used to create the random sequence. However the Yarrow algorithim is written specifically to avoid such clumping and as of yet no one has proven that it does clump. Secondly, you could easily avoid the problem by after filling the image, forcing a reseed by writing the data you want to encrypt into the random device as root, and it would reseed when you closed the write. > 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. Ted
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BMEDLGAENEKCJFGODFOCCEGJCAAA.tedm>