Re: getentropy() support

On Wed, Jun 20, 2018 at 11:13:04PM +0000, Taylor R Campbell wrote:
> > Date: Wed, 20 Jun 2018 18:41:20 +0200
> > From: Kurt Roeckx <[email protected]>
> > 
> > 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.
> > > 
> > > 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.
> > 
> > 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'.

It is. You never want to feed predictable numbers in the CSPRNG.
This totally breaks the security of the whole system.

If it's not initialized, it will give you predictable numbers.
You do not want to write code for every OS to try and figure out
that it has actually been initialized. It makes no sense at all to
ever return a number that it supposed to be random but isn't.

That /dev/urandom on some OSs returns something when it's not
intialized is broken behaviour that never should have been
introduced in the first place. Some OSs like OpenBSD and FreeBSD
get this right and will never return a value if it's not been
initialized, there is no difference between /dev/random and
/dev/urandom.

Having every application reading 1 byte from /dev/random and then
switching to /dev/urandom is really a horrible workaround. It's a
new API, get it right from the first time.

> This is about software that
> will break when deployed in the field because in the testing
> environment it never exercised the blocking code path.

If you need to read 1 byte from /dev/random, and then read from
/dev/urandom, and you never block on reading from /dev/random
because your OS does the right thing, and then in the field it
doesn't, you're really in the same situation.

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

Sure, everybody has access to TRNG.

> 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.

Some OSs initialized the kernel RNG as part of the bootloader,
it will never block. Others will initialize it with a seed file
from userspace, and you need to make sure you do this early
enough.


Kurt