On Wed, Mar 14, 2018 at 01:26:38AM +0000, Salz, Rich wrote:
> So a major reason, as you explained, for having per-thread DRBG's is to
> reduce contention. When threadA creates an SSL object, the parent DRBG will
> be the threadA one. Therefore you have to introducing locking, since threadA
> might create two SSL objects and they could end up being used in threadB and
> threadC and each need to reseed from their parent. In order to do that
> safely, threadA also has to do the locking to avoid conflict. That defeats
> the major gain of per-thread.
> I think having the SSL object parent be whatever the *current* thread DRBG is
> seems like the best, if not only, way to go.
Either that or just always use the per-thread DRBG for the current
thread, and don't bother to do per-SSL at all.
openssl-project mailing list