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.pie...@ncp-e.com> Sent: 05 April 2021 03:22 PM To: Dr Paul Dale<mailto:pa...@openssl.org>; Vishwanath Mahajanshetty<mailto:mahajanshe...@outlook.com>; openssl-users@openssl.org<mailto:openssl-users@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.pie...@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-boun...@openssl.org> On Behalf Of Dr Paul Dale Sent: Monday, April 5, 2021 3:18 AM To: openssl-users@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
