Re: getrandom and getentropy

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

On Sun, May 10, 2020 at 02:24:00PM +0300, Andreas Gustafsson wrote:
> The getentropy() man pages on OpenBSD, FreeBSD, and Linux all say it
> returns "high-quality" entropy, and do not caution against using it
> for security critical purposes such as key generation, so presumably
> applications do in fact use if for such purposes.  Given that,
> implementing it as getrandom(..., GRND_INSECURE) seems like a bad
> idea.
> 
> Also, two of the man pages explicitly mention blocking, so any
> portable software using getentropy() should already deal with it.
> So why not do the safe thing and implement it as getrandom(..., 0)
> == read from /dev/random?
> -- 
> Andreas Gustafsson, gson%gson.org@localhost

For years, the development hivemind's advice has been "/dev/random bad!
always urandom!", because having interfaces that unpredictably block on
you is a terrible idea.

As such, there's a hell of a lot of software out there that relies on
urandom (... "GRND_INSECURE", KERN_ARND equivalent in behaviour on
NetBSD) for tasks such as key generation, under the assumption it's
Good Enough. Tracking down all the instances of this (e.g. in scripts)
would take you a long time.

After some pushing, I'm fairly confident that NetBSD should enter
userland with a good-as-possible state for all observable random
number generators. After several reboots, on a long lived system,
it'll be in an even better state. Blocking should /only/ be observed
by applications that are started early in the life of a system that
/cannot/ provide enough entropy (because the hardware is old or very
low end, with few useful sources), or a system that's been initialized
improperly (with a bad on-disk seed). In this case the kernel makes sure
the operator is aware that the system is in a dangerous state.

I think the naming (INSECURE is deeply scary) and general design of
the Linux interface is unfortunate. It pushes people towards bad
things, and misconceptions about how randomness actually works.

If implemented as described, GRND_INSECURE would not be particularly
scary on a typical NetBSD system.

Of course, none of this is at all helpful if there's doubt as to
whether the trusted sources of randomness actually can't be trusted
(plausible when running a VM on an untrusted host machine, less
plusible but still possible otherwise).

In which case, we're all screwed, regardless of our interfaces.