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: 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  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 fi

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





smime.p7s
Description: S/MIME cryptographic signature

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

[Dr Paul Dale]

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-requ...@openssl.org 


*Sent: *03 April 2021 02:19 PM
*To: *openssl-users@openssl.org 
*Subject: *openssl-users Digest, Vol 77, Issue 6

Send openssl-users mailing list submissions to
    openssl-users@openssl.org

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
    openssl-users-requ...@openssl.org

You can reach the person managing the list at
    openssl-users-ow...@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 
To: openssl-users@openssl.org
Subject: Re: openssl-users Digest, Vol 77, Issue 4
Message-ID: 
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-requ...@openssl.org
> 

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: 
openssl-users-requ...@openssl.org
Sent: 03 April 2021 02:19 PM
To: openssl-users@openssl.org
Subject: openssl-users Digest, Vol 77, Issue 6

Send openssl-users mailing list submissions to
openssl-users@openssl.org

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
openssl-users-requ...@openssl.org

You can reach the person managing the list at
openssl-users-ow...@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 
To: openssl-users@openssl.org
Subject: Re: openssl-users Digest, Vol 77, Issue 4
Message-ID: 
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-requ...@openssl.org
> 
> *Sent: *02 April 2021 04:58 PM
> *To: *openssl-users@openssl.org 
> *Subject: *openssl-users Digest, Vol 77, Issue 4
>
> Send openssl-users mailing list submissions to
> ??? openssl-users@openssl.org
>
> To subscribe