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 _______________________________________________ openssl-project mailing list email@example.com https://mta.openssl.org/mailman/listinfo/openssl-project