Plentiful unpredictable randomness

[Andreas Gustafsson <gson%gson.org@localhost>]

Taylor R Campbell wrote:
> It has become popular to redefine the traditional semantics of
> /dev/random or /dev/urandom so that one or both will block once at
> boot until the OS thinks the entropy pool may have been seeded, and
> then never block again.

IMO, those are the most useful semantics for a /dev/*random device,
and NetBSD ought to provide a device that works this way.

This would combine the advantages of the existing /dev/random and
/dev/urandom by providing randomness that is both unpredictable (like
/dev/random) and plentiful (like /dev/urandom) once seeded.  It would
not solve the problem of /dev/random blocking forever when a system
has no entropy available at all, but it would solve the more common
problem of it blocking due to becoming "exhausted" from use.

I expect there will be strong differences in opinion as to whether
/dev/random and/or /dev/urandom should be changed to work like this,
but we could start by implementing it under a third name so that at
least those of us who want it can use it.  An implementation might
also help clarify the debate by serving as a concrete example of what
the new semantics might be.

> I don't want to do this because code paths that may block but only
> in extreme circumstances, like early at boot on an embedded system,
> are likely never to be exercised even during what might otherwise be
> extensive testing, and as noted blocking when not expected can have
> severe consequences.

That's only an issue with changing /dev/urandom to block until seeded
(I happen to think that ought to be done regardless, but reasonable
people may disagree).  There is no such issue with changing
/dev/random to no longer block once seeded.

Full disclosure: I sell hardware random number generators for a
living.  What I'm proposing here could in theory either increase or
decrease the demand for my products - I'm not sure which.
-- 
Andreas Gustafsson, gson%gson.org@localhost