OpenSSL default DRBG locking query #32616
|
We operate in multi threaded environment and we are using OpenSSL default DRBG for random number generation via RAND_bytes. |
Replies: 2 comments 1 reply
|
Yes, you should support locking. The seed source is only infrequently accessed, so this oughtn't be much of an overhead. |
|
Can you please confirm - Is it correct that the default OpenSSL 3.x DRBG (the thread-local public DRBG plus the shared private/parent chain) is itself thread-safe — i.e., multiple threads calling RAND_bytes() concurrently don't need any additional locking on the caller's part, since the DRBG core already serializes access to the shared/parent DRBG state internally? I want to confirm this is still just about our seed-source provider needing its own locking (via OSSL_FUNC_rand_enable_locking) for fetching entropy, not something that's also required around RAND_bytes() calls themselves. |
|
Yes, RAND_bytes() is thread safe. However this only holds if the seed source is also thread safe since it can be used to reseed. |
Yes, RAND_bytes() is thread safe.
However this only holds if the seed source is also thread safe since it can be used to reseed.