> 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. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev