<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body>
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.<br>
<br>
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.<br>
<br>
<br>
Pauli<br>
<br>
<div class="moz-cite-prefix">On 3/4/21 6:41 pm, Vishwanath
Mahajanshetty wrote:<br>
</div>
<blockquote type="cite"
cite="mid:DM6PR02MB52259E8B1FE80DA574347118BB799@DM6PR02MB5225.namprd02.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style>@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}.MsoChpDefault
{mso-style-type:export-only;}div.WordSection1
{page:WordSection1;}</style>
<div class="WordSection1">
<p class="MsoNormal">Thank You Paul and Matthias for your help.</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The reason I am trying to have separate
RAND_METHOD for two threads is, the first thread which runs
DNS
<b>bind</b> 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.
<span
style="font-family:"Arial",sans-serif;color:black;background:#D5E1E8">dst__entropy_getdata()
</span> from bind code is doing this. I am not sure under what
cases it enters into blocking mode.</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">So If I use this RND_METHOD in second
thread (basically this thread does different task of handling
<b>DoT</b>, 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.</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">As you mentioned, I tried to look into
implementation of RAND_bytes() and drbg_bytes().</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">When SSL_CTX_new() calls RAND_bytes(), it
calls RAND_get_rand_method() which returns RAND_METHOD set by
<b>bind</b> thread. So if I avoid configuring RAND_METHOD in <b>bind</b>
thread, then RAND_get_rand_method() will return
<b>rand_meth </b>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.</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">So I am still confused how can I do <b>bind</b>
thread to use its own RAND_METHOD and
<b>DoT</b> 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?).</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thank You,</p>
<p class="MsoNormal">Vishwanath M</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div
style="mso-element:para-border-div;border:none;border-top:solid
#E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="border:none;padding:0cm"><b>From:
</b><a href="mailto:openssl-users-request@openssl.org"
moz-do-not-send="true">openssl-users-request@openssl.org</a><br>
<b>Sent: </b>02 April 2021 04:58 PM<br>
<b>To: </b><a href="mailto:openssl-users@openssl.org"
moz-do-not-send="true">openssl-users@openssl.org</a><br>
<b>Subject: </b>openssl-users Digest, Vol 77, Issue 4</p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Send openssl-users mailing list submissions
to<br>
<a class="moz-txt-link-abbreviated" href="mailto:openssl-users@openssl.org">openssl-users@openssl.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a
href="https://mta.openssl.org/mailman/listinfo/openssl-users"
moz-do-not-send="true">https://mta.openssl.org/mailman/listinfo/openssl-users</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a class="moz-txt-link-abbreviated" href="mailto:openssl-users-request@openssl.org">openssl-users-request@openssl.org</a><br>
<br>
You can reach the person managing the list at<br>
<a class="moz-txt-link-abbreviated" href="mailto:openssl-users-owner@openssl.org">openssl-users-owner@openssl.org</a><br>
<br>
When replying, please edit your Subject line so it is more
specific<br>
than "Re: Contents of openssl-users digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: Regarding RAND_set_rand_method (Dr Paul Dale)<br>
2. RE: Regarding RAND_set_rand_method (Dr. Matthias St.
Pierre)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Fri, 2 Apr 2021 16:51:28 +1000<br>
From: Dr Paul Dale <a class="moz-txt-link-rfc2396E" href="mailto:pauli@openssl.org"><pauli@openssl.org></a><br>
To: <a class="moz-txt-link-abbreviated" href="mailto:openssl-users@openssl.org">openssl-users@openssl.org</a><br>
Subject: Re: Regarding RAND_set_rand_method<br>
Message-ID:
<a class="moz-txt-link-rfc2396E" href="mailto:1781ab4c-2e2b-fa3b-8b3c-fb4fc5bd3371@openssl.org"><1781ab4c-2e2b-fa3b-8b3c-fb4fc5bd3371@openssl.org></a><br>
Content-Type: text/plain; charset="windows-1252";
Format="flowed"<br>
<br>
There isn't an easy a way to do what you want in 1.1.1. <br>
RAND_set_rand_method replaces the RNG for all of OpenSSL.? In
theory <br>
your RAND_METHOD could detect which thread it is running in
and do <br>
different things for each.? I'm not sure this is a good idea
however.<br>
<br>
Why aren't the random number from your first thread good
enough for the <br>
second?? Good random numbers are just that - random.? It
should be <br>
impossible to distinguish the two streams.<br>
<br>
In OpenSSL 3.0 there are ways to achieve what you're wanting.<br>
<br>
<br>
Pauli<br>
<br>
On 2/4/21 4:24 pm, Vishwanath Mahajanshetty wrote:<br>
><br>
> Hi,<br>
><br>
> I have some doubts/questions on how to use methods (for
ex: <br>
> RAND_set_rand_method) in multi threaded application which
use OpenSSL. <br>
> In my application (running on OpenSSL 1.1.1d) there are
two threads <br>
> which use OpenSSL, both threads perform very different
operations. The <br>
> issue I am facing is as below:<br>
><br>
> Thread T1 calls RAND_set_rand_method() and sets
RAND_METHOD structure. <br>
> This is very specific to T1s use case. When thread T2
wants to create <br>
> SSL_CTX it calls SSL_CTX_new() which then calls
RAND_priv_bytes(). I <br>
> am observing that the function RAND_priv_bytes() is
calling the <br>
> function set by T1 by RAND_METHOD in
RAND_set_rand_method().<br>
><br>
> Essentially RAND_METHOD function set by thread T1 are
getting called <br>
> by thread T2.<br>
><br>
> *Q1: I want to know is there any way to avoid this
problem? I want <br>
> thread T2 to call default RAND methods and avoid calling
methods set <br>
> by thread T1. This is not only for RAND methods, but for
any other <br>
> methods.*<br>
><br>
> **<br>
><br>
> Q2: Also, is it possible to run OpenSSL as separate
instance per <br>
> thread (where each thread can do its own OpenSSL
initialization) so <br>
> that they can avoid above mentioned problem?<br>
><br>
> Thank you,<br>
><br>
> Vishwanath M<br>
><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a
href="https://mta.openssl.org/pipermail/openssl-users/attachments/20210402/58bcb71b/attachment-0001.html"
moz-do-not-send="true">https://mta.openssl.org/pipermail/openssl-users/attachments/20210402/58bcb71b/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Fri, 2 Apr 2021 11:27:53 +0000<br>
From: "Dr. Matthias St. Pierre"
<a class="moz-txt-link-rfc2396E" href="mailto:Matthias.St.Pierre@ncp-e.com"><Matthias.St.Pierre@ncp-e.com></a><br>
To: Dr Paul Dale <a class="moz-txt-link-rfc2396E" href="mailto:pauli@openssl.org"><pauli@openssl.org></a>,
<a class="moz-txt-link-rfc2396E" href="mailto:openssl-users@openssl.org">"openssl-users@openssl.org"</a><br>
<a class="moz-txt-link-rfc2396E" href="mailto:openssl-users@openssl.org"><openssl-users@openssl.org></a><br>
Subject: RE: Regarding RAND_set_rand_method<br>
Message-ID: <a class="moz-txt-link-rfc2396E" href="mailto:7056523443ae4f94bca32240c4f24533@ncp-e.com"><7056523443ae4f94bca32240c4f24533@ncp-e.com></a><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
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.<br>
<br>
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?<br>
<br>
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.<br>
<br>
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.<br>
<br>
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:<br>
<br>
<a
href="https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/crypto/rand/drbg_lib.c#L958-L970"
moz-do-not-send="true">https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/crypto/rand/drbg_lib.c#L958-L970</a><br>
<br>
<br>
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?<br>
<br>
No. If you really need something like that, you might want to
consider splitting your two threads into two processes.<br>
<br>
HTH,<br>
Matthias<br>
<br>
<br>
<br>
From: openssl-users <a class="moz-txt-link-rfc2396E" href="mailto:openssl-users-bounces@openssl.org"><openssl-users-bounces@openssl.org></a>
On Behalf Of Dr Paul Dale<br>
Sent: Friday, April 2, 2021 8:51 AM<br>
To: <a class="moz-txt-link-abbreviated" href="mailto:openssl-users@openssl.org">openssl-users@openssl.org</a><br>
Subject: Re: Regarding RAND_set_rand_method<br>
<br>
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.<br>
<br>
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.<br>
<br>
In OpenSSL 3.0 there are ways to achieve what you're wanting.<br>
<br>
<br>
Pauli<br>
On 2/4/21 4:24 pm, Vishwanath Mahajanshetty wrote:<br>
Hi,<br>
<br>
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:<br>
<br>
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().<br>
<br>
Essentially RAND_METHOD function set by thread T1 are getting
called by thread T2.<br>
<br>
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.<br>
<br>
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?<br>
<br>
Thank you,<br>
Vishwanath M<br>
<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a
href="https://mta.openssl.org/pipermail/openssl-users/attachments/20210402/53153b3a/attachment.html"
moz-do-not-send="true">https://mta.openssl.org/pipermail/openssl-users/attachments/20210402/53153b3a/attachment.html</a>><br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: smime.p7s<br>
Type: application/pkcs7-signature<br>
Size: 7494 bytes<br>
Desc: not available<br>
URL: <<a
href="https://mta.openssl.org/pipermail/openssl-users/attachments/20210402/53153b3a/attachment.bin"
moz-do-not-send="true">https://mta.openssl.org/pipermail/openssl-users/attachments/20210402/53153b3a/attachment.bin</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
openssl-users mailing list<br>
<a class="moz-txt-link-abbreviated" href="mailto:openssl-users@openssl.org">openssl-users@openssl.org</a><br>
<a
href="https://mta.openssl.org/mailman/listinfo/openssl-users"
moz-do-not-send="true">https://mta.openssl.org/mailman/listinfo/openssl-users</a><br>
<br>
<br>
------------------------------<br>
<br>
End of openssl-users Digest, Vol 77, Issue 4<br>
********************************************<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</blockquote>
<br>
</body>
</html>