/dev/random question

[RW]

On Mon, 17 Sep 2007 03:10:30 -0700
"Ted Mittelstaedt" <tedm at toybox.placo.com> wrote:

> 
> 
> > -----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.

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.