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
