/dev/random question

[Ted Mittelstaedt]

> -----Original Message-----
> From: owner-freebsd-questions at freebsd.org
> [mailto:owner-freebsd-questions at freebsd.org]On Behalf Of RW
> Sent: Sunday, September 16, 2007 7:24 PM
> To: freebsd-questions at freebsd.org
> Subject: Re: /dev/random question
>
>
> On Sun, 16 Sep 2007 23:51:56 +0200
> Mel <fbsd.questions at 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