On 12/22/2015 09:32 AM, Imran Ali wrote: > Thanks Steve, > > I was more concerned on the news that openssl may not be FIPS > compliant because of: > > 'sunsetting' older FIPS validations and the reasoning behind the > change has to do with the Random Number Generators (RNG). As of > December 31, 2015, ANSI X9.31 and X9.62 RNG's will no longer be > allowed for use in FIPS mode, leaving us the Random Bit Generators > (RBG) of NIST SP 800-90 That's the "paper shuffle" referenced earlier, and in this earlier post in this same thread: https://mta.openssl.org/pipermail/openssl-users/2015-December/002562.html Thanks to Datagravity that "paper shuffle" is being addressed. The test lab has the necessary paperwork and there is nothing more we can do other than wait on the process. > My understanding based on this is that any applications using ANSI > X9.31 and X9.62 functions under FIPS mode will no longer be compliant > however the whole openssl will still be FIPS compliant but need > paper-shuffle to mark these changes. Am I correct with my assumption > on this? Kinda-sorta. The "sunset" issue isn't *use* of X9.31, which is not the default for the OpenSSL FIPS Object Module and not used anywhere with the module as far as I know. The issue is that any validations that implement *both* X9.31 RNG *and* one or more DRBGs will be yanked without the paper shuffle, regardless of any actual use of X9.31 with those modules. The paper shuffle basically consists of removing most mentions of X9.31 RNG from the Security Policy document. Any application that has deliberately and explicitly enabled a non-default use of the X9.31 RNG would need to be changed, independently of the paper shuffle, but I doubt there are any such applications. -Steve M. -- Steve Marquess OpenSSL Software Foundation 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
