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

[Salz, Rich]

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

Yes I think we will need to support it, such as systems that don't have kernel support.  Always whitening doesn't hurt, so I would like to see the simpler logic of always doing it.  And also for the case where existing applications mix in their own. 

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

In order to maintain conceptual compatibility with the current API, I think that when someone does RAND_poll or RAND_add, they are expecting it to be be used.  I think having a "added_count" field in every pool, and doing a check is simple way to ensure that changes to the global pool propagate down.

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

Is there any reason why this is better than the other mechanisms?

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

We're not yet in the ideal world, and all the world's not a modern Linux kernel :)  I believe we need to give applications an "escape hatch" to let them read/write the global state.  And also think of embedded devices where perhaps the state is in NVRAM.