My thoughts.

Entropy should be whitened.  Anything feed into an entropy pool, should be 
mixed in and run through SHA256.
                pool = SHA256(pool || new-entropy)

The current read and write file routines, and the current routine RAND_poll, 
etc., will add to that global pool.  The idea of cascading pools is neat.  We 
need at least one per thread, using our existing thread-local-storage API.  The 
current “lazy evaluation” will work fine, we don’t need a create-thread API.  
We do need fork/exec protection which is the point of 
https://github.com/openssl/openssl/pull/3754

Each pool should have an atomic counter that is incremented when entropy 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.

Per-thread pools don’t need a lock.  The global and other pools do.  Putting a 
pool in the SSL_CTX is probably reasonable.  I seriously doubt the SSL object 
needs it because the number of random bytes to generate keys is pretty small – 
we’ll expose things through AES misused first :)  But adding it to the SSL 
object is simple so we might as well.

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?

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-entropy 
situations like system boot.

We want to provide a platform-neutral API that makes it’s best effort attempt 
to get entropy from the system and merge it into the global pool.  That should 
be a new API; I suggested RAND_poll_system above, but don’t really care

Does this make sense?  Are there holes?

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Reply via email to