Re: Question regarding lock of the master drbg during the fork

[Dr Paul Dale]

Сергей ,

We are aware that we do not handle the fork(2) system call perfectly.  My 
advice would be to not hold a lock while calling fork(2).  OpenSSL, as of 
1.1.0, does hold per-process locks itself.  The locking callbacks were present 
in 1.0.2 and before but are now obsolete.

Even if it isn’t perfect, OpenSSL does attempt to reseed the DRBG chains when 
fork(2) is called.  This is not designed to meet any of the NIST requirements.  
Rather it is to ensure that the parent and child processes have different 
random seed material.  High quality random numbers are critical to security — 
they are the foundation upon which everything else is based.  OpenSSL tries to 
not take any shortcuts here.  The DRBG chains are part of the considered 
solution — the public and private DRBGs are distinct and a compromise of one 
shouldn’t impact the other; they are also per thread which shouldn’t negatively 
impact performance (by locking).


Спасибо,

Pauli
(my Русский is very rusty)
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia




> On 28 Aug 2019, at 6:51 pm, Сергей Юнаковский  wrote:
> 
> Hello,
> I have a question regarding the usage of the master DRBG during the fork 
> operation. As far as I understand from the source code and articles, during 
> the fork the library will perform the lock of the master DRBG to obtain the 
> entropy for public and private DRBG. 
> However, the library does not perform the check of the lock state itself and 
> it is unclear for me, what will happen if the master DRBG is locked during 
> the creation of the fork process. 
> 
> Additionally, what was the purpose of such complicated scheme for DRBGs 
> except for NIST requirements?  Is it possible to solve fork problem without 
> implementing the chain of DRBGs?
> 
> Can you please help with this?
> 
> Articles:
> https://www.openssl.org/docs/man1.1.1/man7/RAND_DRBG.html 
> 
> http://emboss.github.io/blog/2013/08/21/openssl-prng-is-not-really-fork-safe/ 
> 
> https://wiki.openssl.org/index.php/Random_fork-safety 
> 
> 
> Here is the code from the rand_lib.c:
> rand_drbg_lock(drbg->parent);
> if (RAND_DRBG_generate(drbg->parent,
>buffer, bytes_needed,
>prediction_resistance,
>NULL, 0) != 0)
> bytes = bytes_needed;
> drbg->reseed_next_counter
> = tsan_load(>parent->reseed_prop_counter);
> rand_drbg_unlock(drbg->parent);

Question regarding lock of the master drbg during the fork

[Сергей Юнаковский]

Hello,
I have a question regarding the usage of the master DRBG during the fork
operation. As far as I understand from the source code and articles, during
the fork the library will perform the lock of the master DRBG to obtain the
entropy for public and private DRBG.
However, the library does not perform the check of the lock state itself
and it is unclear for me, what will happen if the master DRBG is locked
during the creation of the fork process.

Additionally, what was the purpose of such complicated scheme for DRBGs
except for NIST requirements?  Is it possible to solve fork problem without
implementing the chain of DRBGs?

Can you please help with this?

Articles:
https://www.openssl.org/docs/man1.1.1/man7/RAND_DRBG.html
http://emboss.github.io/blog/2013/08/21/openssl-prng-is-not-really-fork-safe/
https://wiki.openssl.org/index.php/Random_fork-safety

Here is the code from the rand_lib.c:
rand_drbg_lock(drbg->parent);
if (RAND_DRBG_generate(drbg->parent,
buffer, bytes_needed,
prediction_resistance,
NULL, 0) != 0)
bytes = bytes_needed;
drbg->reseed_next_counter
= tsan_load(>parent->reseed_prop_counter);
rand_drbg_unlock(drbg->parent);