Re: getrandom and getentropy

[nia <nia%NetBSD.org@localhost>]

On Mon, May 11, 2020 at 04:28:51PM +0300, Andreas Gustafsson 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).
> -- 
> Andreas Gustafsson, gson%gson.org@localhost

How are you measuring "full entropy"?
We no longer attempt to estimate the value of the majority of samples
fed into the pool - it was deemed unscientific.

As Taylor mentioned, OpenBSD operates under the under the premise
that either there's a HWRNG, saved seed, or there's enough entropy in
timing &c.  measurements early at boot (or that the kernel using the
RNG lots is enough to put it into an unpredictable state, as Theo
is insisting). All of that depends on assumptions and trust - it
does no measurement of the value of the entropy being provided.

Do you believe that timing samples are enough? The NetBSD kernel doesn't -
that puts us into an "interesting" situation on hardware with no HWRNG.
This hardware can reasonably block forever on first boot, due to
the large number of sources of entropy that are no longer measured.

Even then, can you fully trust HWRNG? There is no magic guarantee of
safety unless you have a fully audited atomic decay measurement device
at your disposal. Most people don't, so we rely on good-as-unpredictable.

Following the logic that even with consolidation of available entropy,
never blocking is inherently unsafe due to the early-in-first-boot
characteristics of old and low end hardware, you'd have to also assume
every single key ever generated on a NetBSD machine is unsafe, because
every significant security library targeting NetBSD either uses
kern.arandom or /dev/urandom.

Since so many projects have recently happily accepted my patches to use
kern.arandom with full understanding of how it works, we already have a
nonblocking, sandbox-safe source of randomness in wide use for security
critical applications on NetBSD. I only want to make it easier for
developers to access, and not harder.