openssl-users Digest, Vol 77, Issue 6

Tue Apr 6 15:51:24 UTC 2021

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: Dr. Matthias St. Pierre<mailto:Matthias.St.Pierre at ncp-e.com>
Sent: 05 April 2021 03:22 PM
To: Dr Paul Dale<mailto:pauli at openssl.org>; Vishwanath Mahajanshetty<mailto:mahajanshetty at outlook.com>; openssl-users at openssl.org<mailto:openssl-users at openssl.org>
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
matthias.st.pierre at ncp-e.com
Phone: +49 911 9968-0
www.ncp-e.com

Follow us on:
 Facebook<https://www.facebook.com/NCPengineering> | Twitter<https://twitter.com/NCP_engineering> | Xing<https://www.xing.com/companies/ncpengineeringgmbh> | YouTube<https://www.youtube.com/user/NCPengineeringGmbH> | LinkedIn<http://www.linkedin.com/company/ncp-engineering-inc.?trk=cws-cpw-coname-0-0>

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 <openssl-users-bounces at openssl.org> On Behalf Of Dr Paul Dale
Sent: Monday, April 5, 2021 3:18 AM
To: openssl-users at openssl.org
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210406/3388ffed/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NCP_logo_2f45208a-c14d-4000-bcd3-1ab400c0e48c.gif
Type: image/gif
Size: 2815 bytes
Desc: NCP_logo_2f45208a-c14d-4000-bcd3-1ab400c0e48c.gif
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210406/3388ffed/attachment-0001.gif>