On Wed, Dec 11, 2013, Tomas Mraz wrote: > On Út, 2013-12-10 at 14:45 +0100, Dr. Stephen Henson wrote: > > On Mon, Dec 09, 2013, geoff_l...@mcafee.com wrote: > > > > > Shouldn't the code read: > > > > > > if (!FIPS_mode()) > > > CRYPTO_w_[un]lock(CRYPTO_LOCK_RAND); > > > > > > Note the '!' operator. > > > > > > > Yes it should, sorry about that. Fixed now. > > But given skipping the locking in the FIPS mode doesn't that mean that > the reseed operation is now not being protected under lock at all? The > FIPS DRBG does not lock before calling the add/reseed callbacks. >
The automatic reseeding is covered as that happens in fips_drbg_bytes which is handled under CRYPTO_LOCK_RAND. If an application explicitly obtains the default DRBG context and reseeds it then no that isn't covered. Given that the FIPS module can't be readily changed the options are somewhat limited. Another possibility I was considering, was to use a different lock ID for the FIPS RAND locking: that can be done with some minor changes in the locking callback mechanism for the module. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
