Re: getentropy() support

> Date: Wed, 20 Jun 2018 18:41:20 +0200
> From: Kurt Roeckx <[email protected]>
>=20
> On Wed, Jun 20, 2018 at 03:49:44PM +0000, Taylor R Campbell wrote:
> > > From: Kurt Roeckx <[email protected]>
> > > - It blocks when the kernel CSRNG hasn't been initialized yet.
> >=20
> > The blocking behaviour isn't documented in
> > <http://man.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/getentropy=
.2>,
> > and I don't think it would be a good idea.  In particular, if a system
> > call _might_ block, it should do so regularly so that the blocking
> > code path is exercised, rather than only once in a great while and
> > especially not during interactive testing.
>=20
> For OpenBSD it's like expected behaviour, why would you return
> insecure random numbers. What is the point in documenting that
> it's not insecure? But if it helps, I can ask them to document that
> part.

This is not about `secure' vs `insecure'.  This is about software that
will break when deployed in the field because in the testing
environment it never exercised the blocking code path.

The security of the system comes from system engineering to ensure the
deterministic software process is wired to a high-entropy
nondeterministic physical process.

If we adopt this with the blocking behaviour, it should flip a coin to
decide whether to block so that the blocking code path is always
exercised, not just early at boot.  But it's also silly to add new
ways of blocking that don't compose like with select or kevent.

Code paths that are exerciesd only with very low probability and
nonuniformly distributed over time are bad news -- see, for example,
failures that arise as a consequence of the stupid design of POSIX
clocks, or how obnoxious it is when you run `gpg --gen-key' to be
asked to bang on the keyboard for superstitious reasons.

Here's a much simpler way to do the system engineering:

1. Make sure you have a hardware RNG, or a seed file, in your system.
2. In /etc/rc.local or wherever, before launching all the applications
   that need to generate key material, read a single byte from
   /dev/random.

Then there is no need to block ever again after that (although reading
from /dev/random periodically while you're testing things will block
now and then).  And there's no need to have APIs that _might_ block
sometimes but only with extremely low probability and nonuniform
distribution in time.