[openssl-dev] Work on a new RNG for OpenSSL

[Kurt Roeckx]

On Mon, Jun 26, 2017 at 04:17:41PM +0000, Salz, Rich via openssl-dev wrote:
>  
> > > Is it worth reposting my thoughts with your suggested wording changes?
> > 
> > OK.  Off-list or on.  This stuff is important.
> 
> Reposting.
> 
> My thoughts.
> 
> Randomness should be whitened.  Anything feed into an randomness pool, should be mixed in and run through SHA256.
>                 pool = SHA256(pool || new-randomness)

Do you think we need to use multiple sources of randomness? I
think we should only use the one source, the one provided by the
kernel. All sources of randomness already go in it, there is no
need for us to try add any other source that it's already using.

So there should be no need to do any whitening.

> Each pool should have an atomic counter that is incremented when randomness is added.  Descendant pools can compare counters and mix in their parent when the counters don’t match.  Then when RAND_poll is called, or perhaps a new routine RAND_poll_system, it goes into the global pool and eventually all other pools will get it (whitened with their current state).  RAND_poll isn’t documented.

The only thing the pool should care about is that it's been
initialized or not, and if it needs to add more data to it or not.

> Then to generate random bytes use ChaCha.  See, for example, http://gitweb.dragonflybsd.org/dragonfly.git/blob/2aa3f894bd9b5b8f58a1526adb26663405b91679:/sys/kern/subr_csprng.c  My first thoughts on reading that code were, wow, is it really that easy?

You might also want to take a look at something like:
https://github.com/smuellerDD/chacha20_drng/blob/master/chacha20_drng.c

> We want to be able to save the current global state – write to a BIO – and restore it – read from a BIO.  This will let us reasonably work in low-randomness situations like system boot.

Ideally we should refuse to operate in a situation where the kernel
didn't initialize it's RNG yet. I only know about Linux being broken
in this regard, and getrandom() / getentropy() really should be
available on them by now. I don't think we should add a workaround
by reading 1 byte from /dev/random if getrandom() isn't available.


Kurt