[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: getrandom and getentropy
On Mon, May 11, 2020 at 05:58:21PM +0300, Andreas Gustafsson wrote:
> 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
> 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.
There is no (good) way to know when full entropy is achived,
fundamentally. That's one of the big issues this whole discussion
started from. That means ensuring that a reasonable level of seeding
and/or initial entropy during boot is a problem of the system
integration. Normally, saving a RNG state before reboot is good enough
with whatever little entropy can be collected even in virtualized
hardware during early boot. It can be a problem if you install a fresh
system and then copy it, but then it is part of SI to either nuke the
seed file or provide a hardware RNG to make it moot. There are no magic
solutions here and pretending that a blocking API helps doesn't fix any
of the problems either.
Main Index |
Thread Index |