RE: Regarding RAND_set_rand_method

["Dr. Matthias St. Pierre" <Matthias.St.Pierre@xxxxxxxxx>]

Re Q1: I want to know is there any way to avoid this problem? I want thread T2 to call default RAND methods and avoid calling methods set by thread T1. This is not only for RAND methods, but for any other methods.

 

First of all, I agree with Pauli: your first question should be, why do you need different random generators for different threads in the same application? Is this necessary, or are you overengineering?

 

Let me clarify some details about the RNG implemention in OpenSSL 1.1.1.: The RAND_METHOD interface itself is not thread aware. It is only the new default RAND_METHOD implementation (added in 1.1.1.) of OpenSSL (RAND_OpenSSL()), which supports thread local random generators. The implementation is based on deterministic random bit generators (DRBG) as described in NIST.SP.800-90Ar1. Wenn a thread calls RAND_bytes() (resp. RAND_priv_bytes()), the call is forwarded to the thread-specific DRBG instance. All per-thread instances reseed from a single global DRBG instance, which in turn reseeds from  from random sources provided by the operating system.

 

In your case, by replacing the RAND_METHOD, you are changing the complete RAND implementation for all threads. Moreover, you are completely responsible yourself for reseeding your RNG properly.

 

You could however implement a smarter RAND_METHOD which calls your specific RNG for T1 and delegates to the thread local DRBG (RAND_DRBG_get0_public() resp. RAND_DRBG_get0_private()) for all other threads. To get an idea how it can be done, take a look at the default implementation of RAND_bytes(),  drbg_bytes() in drbg_lib.c:

 

https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/crypto/rand/drbg_lib.c#L958-L970

 

 

Re Q2: Also, is it possible to run OpenSSL as separate instance per thread (where each thread can do its own OpenSSL initialization) so that they can avoid above mentioned problem?

 

No. If you really need something like that, you might want to consider splitting your two threads into two processes.

 

HTH,

Matthias

 

 

 

From: openssl-users <openssl-users-bounces@xxxxxxxxxxx> On Behalf Of Dr Paul Dale
Sent: Friday, April 2, 2021 8:51 AM
To: openssl-users@xxxxxxxxxxx
Subject: Re: Regarding RAND_set_rand_method

 

There isn't an easy a way to do what you want in 1.1.1.  RAND_set_rand_method replaces the RNG for all of OpenSSL.  In theory your RAND_METHOD could detect which thread it is running in and do different things for each.  I'm not sure this is a good idea however.

Why aren't the random number from your first thread good enough for the second?  Good random numbers are just that - random.  It should be impossible to distinguish the two streams.

In OpenSSL 3.0 there are ways to achieve what you're wanting.


Pauli

On 2/4/21 4:24 pm, Vishwanath Mahajanshetty wrote:

Hi,

 

I have some doubts/questions on how to use methods (for ex: RAND_set_rand_method) in multi threaded application which use OpenSSL. In my application (running on OpenSSL 1.1.1d) there are two threads which use OpenSSL, both threads perform very different operations. The issue I am facing is as below:

 

Thread T1 calls RAND_set_rand_method() and sets RAND_METHOD structure. This is very specific to T1s use case. When thread T2 wants to create SSL_CTX it calls SSL_CTX_new() which then calls RAND_priv_bytes(). I am observing that the function RAND_priv_bytes() is calling the function set by T1 by RAND_METHOD in RAND_set_rand_method().

 

Essentially RAND_METHOD function set by thread T1 are getting called by thread T2.

 

Q1: I want to know is there any way to avoid this problem? I want thread T2 to call default RAND methods and avoid calling methods set by thread T1. This is not only for RAND methods, but for any other methods.

 

Q2: Also, is it possible to run OpenSSL as separate instance per thread (where each thread can do its own OpenSSL initialization) so that they can avoid above mentioned problem?

 

Thank you,

Vishwanath M

 

 

 

Attachment: smime.p7s
Description: S/MIME cryptographic signature