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