krb5 and PRNGs

[Nicolas Williams]

On Tue, Sep 21, 2010 at 06:07:19PM -0400, Greg Hudson wrote:
> On Tue, 2010-09-21 at 17:48 -0400, Nicolas Williams wrote:
> > > We don't use /dev/urandom directly to generate keys.  I assume this is
> > > out of concern that /dev/urandom might not be cryptographically
> > > strong--that is, an attacker might be able to look at some of its
> > > output, recover the internal state of the kernel's PRNG, and know all
> > > of the subsequent outputs.  If /dev/urandom can be attacked in this
> > 
> > No, that's not correct.
> 
> What's not correct?  /dev/urandom *should* have all of the properties
> you mentioned, but if we're willing to assume that, why not just use it
> directly for keys?

There's simply no reason that /dev/urandom on any OS couldn't be a
decent PRNG with a seed taken from /dev/random (at boot time and/or at
shutdown time).  In particular, a /dev/urandom that is not at least a
decent PRNG, however seeded, is a disaster.

As for your second question: I'd like some guarantee of entropy content
before using an entropy source for long-term and even session keys.

> Keep in mind that in the section you quoted, I am trying to intuit the
> design intent of an architecture I myself did not have a hand in; I'm
> not articulating my own views.

Understood :)

My message: if you have that lousy a /dev/urandom, file a bug with the
OS vendor.  (I'm pretty sure Solaris' rocks, and I'd definitely consider
it a high-priority bug if it was as lame as you expect /dev/urandom to
be.)

> > Applications can only do so much to make up for limitations of the host
> > OS' entropy services.  I'd say: use /dev/random to seed Yarrow/Fortuna,
> > and be done.
> 
> Currently, we treat /dev/random as sufficiently precious that we are not
> willing to use it every time the krb5 library is fired up, only for very
> limited purposes (kadmind and kdb5_util create).  We really do
> use /dev/urandom to seed Yarrow, most of the time.
> 
> Also, the whole point of my message is to call into question the
> applicability of the Yarrow/Fortuna reseed logic to Kerberos.  Saying
> "use /dev/random to seed Yarrow/Fortuna, and be done" sidesteps the
> fundamental issue.

I was addressing the matter of what /dev/urandom's semantics should be.

Interestingly, I don't know if /dev/random is expected to support
non-blocking reads.  If it does then I'd try to read as much entropy as
possible to seed Yarrow with, with a short deadline (say, a few
seconds).  I suspect non-blocking I/O on /dev/random is not likely to be
portable, but you could always use alarm(3C) or something more involved
(since it's generally not safe to use alarm(3C) from a library), such as
doing the read() of /dev/random in a worker thread which you'll cancel
if it takes too long to complete.

Nico
--