Re: Plea for a new public OpenSSL RNG API
"Blumenthal, Uri - 0553 - MITLL" <[email protected]> Sun, 3 Sep 2017 17:59:58 -0400
| Newsgroups | gmane.comp.encryption.openssl.devel |
|---|---|
| Message-ID | <[email protected]> |
I like this PR. Thank you! > On Sep 3, 2017, at 17:53, Dr. Matthias St. Pierre <[email protected]> wrote: > >> >> The 'RAND_add()/RAND_bytes()' pattern is broken >> =============================================== >> >> In OpenSSL, the classical way for the RNG consumer to add his own randomness is to call 'RAND_add()' before >> calling 'RAND_bytes()'. If the new 'RAND_OpenSSL()' method (the "compatibility layer" hiding the public >> RAND_DRBG instance) is the default, then this does not work as expected anymore: >> >> The reason is that a call to 'RAND_add()' adds the provided randomness only to a global buffer >> ('rand_bytes'), from which it will be pulled during the next reseed. But no reseed is triggered. So the next >> RAND_bytes() call will be unaffected from the RAND_add(), which is not what the consumer expected. (The same >> holds for 'RAND_seed()', since 'drbg_seed()' only calls into 'drbg_add()') >> >> Reseeding of DRBGs occurs only at the following occasions: >> >> * immediately after a 'fork()' (new) >> * if the 'reseed_counter' exceeds the 'reseed_interval' >> * if 'RAND_DRBG_generate()' is called requesting 'prediction_resistance' >> * 'RAND_DRBG_reseed()' is called explicitely >> >> *Note:* Currently it looks like the situation is even worse: if 'RAND_add()' is called multiple times before >> a reseed occurs, then the result of the previous call is overwritten. > > > I just posted GitHub PR #4328 related to this issue > > [openssl/openssl] WIP: Fix the RAND_add() reseeding issue (#4328) > > > Matthias St. Pierre -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev