[openssl-project] DRBGs, threads and locking

[Benjamin Kaduk]

On Wed, Mar 14, 2018 at 01:27:47AM +0100, Kurt Roeckx wrote:
> My solution is to just have 1 master DRBG, and a public and
> private DRBG per thread. The only lock that then is needed is when
> the public or private DRBG needs to reseed. All the rest of the
> code can stay just as it is, but we might want to change some
> places to use the (thread local) private DRBG, which is what #4665
> is about.
[...]
> So the suggestion was to still have a per SSL public DRBG, but
> then the problem is that that SSL object might have moved to a
> different thread between creating and being used and so that the
> parent DRBG might actually belong to a different thread. One
> solution there is that we just take the current thread's public
> DRBG as parent instead of the original threads public DRBG.

This should be fine from a thread-safety point of view.  I don't
know whether it could potentially affect the standards compliance,
for the intermediate DRBG to potentially change over time (even
though it still chains to a common grandparent/master DRBG).

Per-SSL DRBGs (especially if split to public and private) seem
excessive to me, so architecture described in the quoted text seems
like the best option, to me.

-Ben