RE: openssl-users Digest, Vol 77, Issue 6

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

RE: openssl-users Digest, Vol 77, Issue 6

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

 

 

 

 

From: [hidden email]
Sent: 03 April 2021 02:19 PM
To: [hidden email]
Subject: openssl-users Digest, Vol 77, Issue 6

 

Send openssl-users mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        https://mta.openssl.org/mailman/listinfo/openssl-users
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

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 <[hidden email]>
To: [hidden email]
Subject: Re: openssl-users Digest, Vol 77, Issue 4
Message-ID: <[hidden email]>
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: *[hidden email]
> <[hidden email]>
> *Sent: *02 April 2021 04:58 PM
> *To: *[hidden email] <[hidden email]>
> *Subject: *openssl-users Digest, Vol 77, Issue 4
>
> Send openssl-users mailing list submissions to
> ??????? [hidden email]
>
> 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
> ??????? [hidden email]
>
> You can reach the person managing the list at
> ??????? [hidden email]
>
> 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 <[hidden email]>
> To: [hidden email]
> Subject: Re: Regarding RAND_set_rand_method
> Message-ID: <[hidden email]>
> 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>>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 2 Apr 2021 11:27:53 +0000
> From: "Dr. Matthias St. Pierre" <[hidden email]>
> To: Dr Paul Dale <[hidden email]>, "[hidden email]"
> ??????? <[hidden email]>
> Subject: RE: Regarding RAND_set_rand_method
> Message-ID: <[hidden email]>
> 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>
>
>
> 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 <[hidden email]> On Behalf Of
> Dr Paul Dale
> Sent: Friday, April 2, 2021 8:51 AM
> To: [hidden email]
> 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>>
> -------------- 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>>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> openssl-users mailing list
> [hidden email]
> 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>

------------------------------

Subject: Digest Footer

_______________________________________________
openssl-users mailing list
[hidden email]
https://mta.openssl.org/mailman/listinfo/openssl-users


------------------------------

End of openssl-users Digest, Vol 77, Issue 6
********************************************

 

Reply | Threaded
Open this post in threaded view
|

Re: openssl-users Digest, Vol 77, Issue 6

Dr Paul Dale-2
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: [hidden email]
Sent: 03 April 2021 02:19 PM
To: [hidden email]
Subject: openssl-users Digest, Vol 77, Issue 6

 

Send openssl-users mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        https://mta.openssl.org/mailman/listinfo/openssl-users
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

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 [hidden email]
To: [hidden email]
Subject: Re: openssl-users Digest, Vol 77, Issue 4
Message-ID: [hidden email]
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: *[hidden email]
> <[hidden email]>
> *Sent: *02 April 2021 04:58 PM
> *To: *[hidden email] <[hidden email]>
> *Subject: *openssl-users Digest, Vol 77, Issue 4
>
> Send openssl-users mailing list submissions to
> ??????? [hidden email]
>
> 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
> ??????? [hidden email]
>
> You can reach the person managing the list at
> ??????? [hidden email]
>
> 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 [hidden email]
> To: [hidden email]
> Subject: Re: Regarding RAND_set_rand_method
> Message-ID: [hidden email]
> 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>>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 2 Apr 2021 11:27:53 +0000
> From: "Dr. Matthias St. Pierre" [hidden email]
> To: Dr Paul Dale [hidden email], [hidden email]
> ??????? [hidden email]
> Subject: RE: Regarding RAND_set_rand_method
> Message-ID: [hidden email]
> 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>
>
>
> 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 [hidden email] On Behalf Of
> Dr Paul Dale
> Sent: Friday, April 2, 2021 8:51 AM
> To: [hidden email]
> 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>>
> -------------- 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>>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> openssl-users mailing list
> [hidden email]
> 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>

------------------------------

Subject: Digest Footer

_______________________________________________
openssl-users mailing list
[hidden email]
https://mta.openssl.org/mailman/listinfo/openssl-users


------------------------------

End of openssl-users Digest, Vol 77, Issue 6
********************************************

 


Reply | Threaded
Open this post in threaded view
|

RE: openssl-users Digest, Vol 77, Issue 6

Dr. Matthias St. Pierre

 

> 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.

Well, technically it *is* possible. However, I’m still in doubt whether it is really necessary and should be done.

 

The following example assumes you are compiling for linux (or another unix-ish os) and using pthreads:

Assume that you recorded the thread id of your thread T1 (which you obtained from pthread_create())

in the static variable ‘tid1’. Then you could take the code from [1] and modify it as follows:

 

```

static int my_rand_bytes(unsigned char *out, int count)

{

                int ret;

               

                if (pthread_equal(pthread_self(), tid1) {

                               // ... call your special RNG here

                } else {

               

                               RAND_DRBG *drbg = RAND_DRBG_get0_public();

 

                               if (drbg == NULL)

                                               return 0;

 

                               ret = RAND_DRBG_bytes(drbg, out, count);

                }

 

                return ret;

}

```

 

This is just a rough sketch, note that there are more RAND_METHODs to be considered [2].

 

 

Matthias

 

 

 

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

[2] https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/crypto/rand/drbg_lib.c#L1146-L1153

 

 

 

 

From: openssl-users <[hidden email]> On Behalf Of Dr Paul Dale
Sent: Monday, April 5, 2021 3:18 AM
To: [hidden email]
Subject: Re: openssl-users Digest, Vol 77, Issue 6

 

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

 

 

 

 


smime.p7s (10K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: openssl-users Digest, Vol 77, Issue 6

Vishwanath Mahajanshetty

Hi Matthias,

 

I tried the changes you suggested, it works well. Now T1 can call its own RNG and T2 calls its local DRBG. I don’t find any reasons why it can’t be done this way, may be there are some hidden issues which I have not seen yet but as of now it looks to be working fine. Thank you very much Matthias and Paul for your help on this.

 

Regards,

Vishwanath  M

 

 

 

From: [hidden email]
Sent: 05 April 2021 03:22 PM
To: [hidden email]; [hidden email]; [hidden email]
Subject: RE: openssl-users Digest, Vol 77, Issue 6

 

 

> 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.

Well, technically it *is* possible. However, I’m still in doubt whether it is really necessary and should be done.

 

The following example assumes you are compiling for linux (or another unix-ish os) and using pthreads:

Assume that you recorded the thread id of your thread T1 (which you obtained from pthread_create())

in the static variable ‘tid1’. Then you could take the code from [1] and modify it as follows:

 

```

static int my_rand_bytes(unsigned char *out, int count)

{

               int ret;

              

               if (pthread_equal(pthread_self(), tid1) {

                              // ... call your special RNG here

               } else {

              

                              RAND_DRBG *drbg = RAND_DRBG_get0_public();

 

                              if (drbg == NULL)

                                             return 0;

 

                              ret = RAND_DRBG_bytes(drbg, out, count);

               }

 

               return ret;

}

```

 

This is just a rough sketch, note that there are more RAND_METHODs to be considered [2].

 

 

Matthias

 

 

 

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

[2] https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/crypto/rand/drbg_lib.c#L1146-L1153

 

 

 

 

 

NCP engingeering GmbH

Dr. Matthias St. Pierre

Senior Software Engineer
[hidden email]
Phone: +49 911 9968-0
www.ncp-e.com


Follow us on:

 Facebook | Twitter | Xing | YouTube | LinkedIn

Headquarters Germany: NCP engineering GmbH • Dombuehler Str. 2 • 90449 • Nuremberg
North American HQ: NCP engineering Inc. • 601 Cleveland Str., Suite 501-25 • Clearwater, FL 33755

Authorized representatives: Peter Soell, Patrick Oliver Graf, Beate Dietrich
Registry Court: Lower District Court of Nuremberg
Commercial register No.: HRB 7786 Nuremberg, VAT identification No.: DE 133557619

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Längere Support-Antwortzeiten durch erhöhtes Anfrage-Aufkommen
Aufgrund des anhaltend hohen Anfrage-Aufkommens im Bereich Support und System Engineering kann es aktuell zu längeren Antwortzeiten kommen. Wir setzen alles daran, Ihre Anfragen so schnell wie möglich zu beantworten. Wir bitten Sie hier vorsorglich um Geduld und danken Ihnen für Ihr Verständnis.

Longer support response times due to high number of requests
Due to the continuing high volume of requests, support and system engineering response times may be longer than expected at present. We will do our best to answer your requests as soon as possible. We ask for your patience during this time and appreciate your understanding.

This e-mail message including any attachments is for the sole use of the intended recipient(s) and may contain privileged or confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please immediately contact the sender by reply e-mail and delete the original message and destroy all copies thereof.

 

From: openssl-users <[hidden email]> On Behalf Of Dr Paul Dale
Sent: Monday, April 5, 2021 3:18 AM
To: [hidden email]
Subject: Re: openssl-users Digest, Vol 77, Issue 6

 

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