I think the intention is to ditch the drbg from the ssl object and then call 
the global function (either public or private) which has been changed to use 
the current thread's drbg rather than being global.

I'm in favour of a single per ssl drbg still, I'm not sure what a clean way to 
hook it up to avoid locks is (yet).


Pauli
-- 
Oracle
Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217
Oracle Australia

-----Original Message-----
From: Salz, Rich [mailto:rs...@akamai.com] 
Sent: Wednesday, 14 March 2018 11:27 AM
To: openssl-project@openssl.org
Subject: Re: [openssl-project] DRBGs, threads and locking

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.

 

_______________________________________________
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project
_______________________________________________
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Reply via email to