|
Vishwanath, have you already tried to simply use the default RAND_METHOD and not to replace it by your own? Except for the initial
seeding(*), the thread local DRBGs should operate for a long time without blocking and without interfering with each other. Even if the thread local DRBGs reseed, they obtain their seed from the master DRBG, which does not reseed from the operating system
every time. Even more, the RAND_{priv_}bytes() calls of different threads are completely independent from each other, except for the (unlikely) case that both threads block on the master DRBG which blocks on the
os entropy source. Please also post call stacks of the two threads if the problem persists. In particular, it would be useful to see which
method is used to obtain the entropy (getrandom(), a read() from /dev/[u]random, …), and why the system is so low on entropy. Regards, Matthias (*) you might want to force an initial seeding during application startup by an explicit
RAND_bytes() call.
From: openssl-users
<openssl-users-bounces@xxxxxxxxxxx>
On Behalf Of Vishwanath Mahajanshetty Hi Paul, Thanks for your response. I understand the concern for good random numbers; but in this scenario when second thread calls
SSL_CTX_new it is waiting forever in
RAND_priv_bytes(). Looks like entropy functions defined by first (bind) thread are very specific for its own use case and can’t be used by other treads. So I am thinking of using default OpenSSL RAND_METHOD for second thread and keep first thread (bind) to use its own random number
generators. Please let me know how can I make one thread use default RAND_METHOD and keep other thread to use its own method. I have gone through
RAND_bytes() and drbg_bytes() but not getting enough idea. It would be really helpful if you point out APIs which help me to achieve this requirement. Thank You, Vishwanath M | ||||||
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
