Re: getrandom and getentropy

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

Joerg Sonnenberger wrote:
> > For the OpenBSD strategy to work, the system needs to actually refuse
> > to run if the seed can't be loaded (or full entropy achieved in some
> > other way).  NetBSD doesn't do that.  As long as there is any way
> > userland can start before full entropy has been achieved, all APIs
> > that provide randomness for security purposes must support blocking
> > (or returning errors).
> 
> Why? Like I said, we don't have a working 127.0.0.1 when userland starts
> and that is an essential part of the Unix network stack.

Because if the APIs return data before full entropy has been achieved,
rather than blocking (or failing), the data returned may be
predictable, leading to silent security failures such as the
generation of guessable encryption keys.  I'm not familiar with the
127.0.0.1 issue, but presumably it does not have such security
implications.

Are you suggesting that instead of blocking calls, we should use
something akin to the ordering of rc scripts that ensures 127.0.0.1 is
set up before use to ensure entropy is available before it is needed?
That could work, assuming entropy is available at all, but in that
case any premature calls to the randomness APIs ought to return errors
so that bugs in the ordering can be detected rather than causing
silent generation of predictable randomness.
-- 
Andreas Gustafsson, gson%gson.org@localhost