openssl-users Digest, Vol 77, Issue 6

Dr Paul Dale pauli at openssl.org
Mon Apr 5 01:17:57 UTC 2021


Vishwanath,

It isn't possible to do what you are wanting.  RAND_METHOD replaces the 
RNG everywhere.  It cannot be done on a per thread process.


Pauli

On 4/4/21 9:55 pm, Vishwanath Mahajanshetty wrote:
>
> 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
>
> *From: *openssl-users-request at openssl.org 
> <mailto:openssl-users-request at openssl.org>
> *Sent: *03 April 2021 02:19 PM
> *To: *openssl-users at openssl.org <mailto:openssl-users at openssl.org>
> *Subject: *openssl-users Digest, Vol 77, Issue 6
>
> Send openssl-users mailing list submissions to
>         openssl-users at openssl.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mta.openssl.org/mailman/listinfo/openssl-users 
> <https://mta.openssl.org/mailman/listinfo/openssl-users>
> or, via email, send a message with subject or body 'help' to
>         openssl-users-request at openssl.org
>
> You can reach the person managing the list at
>         openssl-users-owner at openssl.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openssl-users digest..."
>
>
> Today's Topics:
>
>    1. Re: openssl-users Digest, Vol 77, Issue 4 (Dr Paul Dale)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 3 Apr 2021 18:48:48 +1000
> From: Dr Paul Dale <pauli at openssl.org>
> To: openssl-users at openssl.org
> Subject: Re: openssl-users Digest, Vol 77, Issue 4
> Message-ID: <c1d66d09-56da-8d62-96ec-2286b1b65534 at openssl.org>
> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>
> I would be **very** concerned about bypassing a blocking RAND.? It is
> almost certainly blocking because it does not have enough randomness to
> satisfy your request.? By skipping this, you are likely getting poor
> quality random values and this can effectively negate any security you
> are gaining from the encryption.
>
> Good random numbers are fundamental to modern cryptography.? Without
> them, there is no security.? I cannot stress this enough.? Do not try to
> second guess or bypass the RNG.
>
>
> Pauli
>
> On 3/4/21 6:41 pm, Vishwanath Mahajanshetty wrote:
> >
> > Thank You Paul and Matthias for your help.
> >
> > The reason I am trying to have separate RAND_METHOD for two threads
> > is, the first thread which runs DNS *bind* code registers for
> > RAND_METHOD through dnssec module in it. It registers via either
> > ENGINE_set_default_RAND() or RAND_set_rand_method() based on
> > OPENSSL_NO_ENGINE is defined or not. But problem is, under some
> > circumstances the random number generator enters into blocking mode
> > and starts to wait for some events on some FDs and it blocks in
> > select() system call. dst__entropy_getdata() ?from bind code is doing
> > this. I am not sure under what cases it enters into blocking mode.
> >
> > So If I use this RND_METHOD in second thread (basically this thread
> > does different task of handling *DoT*, Dns Over TLS, connections,
> > which is not related to first thread wrt SSL functionalities), then
> > while creating SSL_CTX this thread gets stuck in select() system call
> > randomly (happens very rarely as decided by dst__entropy_getdata());
> > this can happen at any time of SSL connection lifetime whenever it
> > wants to get random data.
> >
> > I agree with you that we should have done this as separate process
> > instead of new thread; but I am trying figure out if I can somehow
> > avoid this situation.
> >
> > As you mentioned, I tried to look into implementation of RAND_bytes()
> > and drbg_bytes().
> >
> > When SSL_CTX_new() calls RAND_bytes(), it calls RAND_get_rand_method()
> > which returns RAND_METHOD set by *bind* thread. So if I avoid
> > configuring RAND_METHOD in *bind* thread, then RAND_get_rand_method()
> > will return *rand_meth *which is OpenSSL default RAND_METHOD; but if I
> > do this change bind thread will move away from its RAND_METHOD
> > functions and start using OpenSSL default functions which may change
> > its behaviour.
> >
> > So I am still confused how can I do *bind* thread to use its own
> > RAND_METHOD and *DoT* thread to use default OpenSSL RAND_METHOD. It
> > would be really helpful if you can explain this with little more
> > details (are there any APIs I can call from one thread to use its
> > specific RAND_METHOD but other threads continue to use OpenSSL default
> > RAND_METHOD?).
> >
> > Thank You,
> >
> > Vishwanath M
> >
> > *From: *openssl-users-request at openssl.org
> > <mailto:openssl-users-request at openssl.org 
> <mailto:openssl-users-request at openssl.org>>
> > *Sent: *02 April 2021 04:58 PM
> > *To: *openssl-users at openssl.org <mailto:openssl-users at openssl.org 
> <mailto:openssl-users at openssl.org>>
> > *Subject: *openssl-users Digest, Vol 77, Issue 4
> >
> > Send openssl-users mailing list submissions to
> > ??????? openssl-users at openssl.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > https://mta.openssl.org/mailman/listinfo/openssl-users 
> <https://mta.openssl.org/mailman/listinfo/openssl-users>
> > <https://mta.openssl.org/mailman/listinfo/openssl-users 
> <https://mta.openssl.org/mailman/listinfo/openssl-users>>
> > or, via email, send a message with subject or body 'help' to
> > ??????? openssl-users-request at openssl.org
> >
> > You can reach the person managing the list at
> > ??????? openssl-users-owner at openssl.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of openssl-users digest..."
> >
> >
> > Today's Topics:
> >
> > ?? 1. Re: Regarding RAND_set_rand_method (Dr Paul Dale)
> > ?? 2. RE: Regarding RAND_set_rand_method (Dr. Matthias St. Pierre)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Fri, 2 Apr 2021 16:51:28 +1000
> > From: Dr Paul Dale <pauli at openssl.org>
> > To: openssl-users at openssl.org
> > Subject: Re: Regarding RAND_set_rand_method
> > Message-ID: <1781ab4c-2e2b-fa3b-8b3c-fb4fc5bd3371 at openssl.org>
> > Content-Type: text/plain; charset="windows-1252"; Format="flowed"
> >
> > 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
> > >
> >
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL:
> > 
> <https://mta.openssl.org/pipermail/openssl-users/attachments/20210402/58bcb71b/attachment-0001.html
> > 
> <https://mta.openssl.org/pipermail/openssl-users/attachments/20210402/58bcb71b/attachment-0001.html 
> <https://mta.openssl.org/pipermail/openssl-users/attachments/20210402/58bcb71b/attachment-0001.html>>>
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Fri, 2 Apr 2021 11:27:53 +0000
> > From: "Dr. Matthias St. Pierre" <Matthias.St.Pierre at ncp-e.com>
> > To: Dr Paul Dale <pauli at openssl.org>, "openssl-users at openssl.org"
> > ??????? <openssl-users at openssl.org>
> > Subject: RE: Regarding RAND_set_rand_method
> > Message-ID: <7056523443ae4f94bca32240c4f24533 at ncp-e.com>
> > Content-Type: text/plain; charset="us-ascii"
> >
> > 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 
> <https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/crypto/rand/drbg_lib.c#L958-L970> 
>
> > 
> <https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/crypto/rand/drbg_lib.c#L958-L970 
> <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 at openssl.org> On Behalf Of
> > Dr Paul Dale
> > Sent: Friday, April 2, 2021 8:51 AM
> > To: openssl-users at openssl.org
> > 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
> >
> >
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL:
> > 
> <https://mta.openssl.org/pipermail/openssl-users/attachments/20210402/53153b3a/attachment.html
> > 
> <https://mta.openssl.org/pipermail/openssl-users/attachments/20210402/53153b3a/attachment.html 
> <https://mta.openssl.org/pipermail/openssl-users/attachments/20210402/53153b3a/attachment.html>>>
> > -------------- next part --------------
> > A non-text attachment was scrubbed...
> > Name: smime.p7s
> > Type: application/pkcs7-signature
> > Size: 7494 bytes
> > Desc: not available
> > URL:
> > 
> <https://mta.openssl.org/pipermail/openssl-users/attachments/20210402/53153b3a/attachment.bin
> > 
> <https://mta.openssl.org/pipermail/openssl-users/attachments/20210402/53153b3a/attachment.bin 
> <https://mta.openssl.org/pipermail/openssl-users/attachments/20210402/53153b3a/attachment.bin>>>
> >
> > ------------------------------
> >
> > Subject: Digest Footer
> >
> > _______________________________________________
> > openssl-users mailing list
> > openssl-users at openssl.org
> > https://mta.openssl.org/mailman/listinfo/openssl-users 
> <https://mta.openssl.org/mailman/listinfo/openssl-users>
> > <https://mta.openssl.org/mailman/listinfo/openssl-users 
> <https://mta.openssl.org/mailman/listinfo/openssl-users>>
> >
> >
> > ------------------------------
> >
> > End of openssl-users Digest, Vol 77, Issue 4
> > ********************************************
> >
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> <https://mta.openssl.org/pipermail/openssl-users/attachments/20210403/e6d569b8/attachment.html 
> <https://mta.openssl.org/pipermail/openssl-users/attachments/20210403/e6d569b8/attachment.html>>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> openssl-users mailing list
> openssl-users at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-users 
> <https://mta.openssl.org/mailman/listinfo/openssl-users>
>
>
> ------------------------------
>
> End of openssl-users Digest, Vol 77, Issue 6
> ********************************************
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210405/bc0fe9bd/attachment-0001.html>


More information about the openssl-users mailing list