Re: Avoid multiple locks in FIPS mode commit to OpenSSL_1_0_1-stable
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. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb (You'll never know whether the road is wrong though.) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Avoid multiple locks in FIPS mode commit to OpenSSL_1_0_1-stable
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
Re: Avoid multiple locks in FIPS mode commit to OpenSSL_1_0_1-stable
On 11 December 2013 08:55, Tomas Mraz tm...@redhat.com 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. Why would you need a lock? FIPS compliant modules are single threaded... (Yes, I know this is stupid). __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Avoid multiple locks in FIPS mode commit to OpenSSL_1_0_1-stable
On Wed, Dec 11, 2013, Ben Laurie wrote: On 11 December 2013 08:55, Tomas Mraz tm...@redhat.com 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. Why would you need a lock? FIPS compliant modules are single threaded... (Yes, I know this is stupid). And they work in single user mode with no other processes running and all hardware is encased in a safe made of pixie dust... One of those is untrue and it says a lot about FIPS that it isn't obvious which one ;-) 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
