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

Reply via email to