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, Сергей Юнаковский <lein360 at gmail.com> 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 <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/ <http://emboss.github.io/blog/2013/08/21/openssl-prng-is-not-really-fork-safe/>
> https://wiki.openssl.org/index.php/Random_fork-safety <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(&drbg->parent->reseed_prop_counter);
>             rand_drbg_unlock(drbg->parent);

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190828/f8f12e9e/attachment-0001.html>