> From: openssl-users <openssl-users-bounces@xxxxxxxxxxx> On Behalf Of Nagarjun J > Sent: Monday, 8 February, 2021 10:33 > What is this SP800-56A REV3 new FIPS requirement, Well, one thing it isn't is "new". Published April 2018, so nearly 3 years ago. See: https://csrc.nist.gov/publications/detail/sp/800-56a/rev-3/final > How it affects ECDH , I believe it mostly affects which curves are permitted, and which are required for security strength > 112 bits. See this description: https://www.doncio.navy.mil/chips/ArticleDetails.aspx?ID=9667 > how it is different from openssl-2.0.16 ECDH implication. Presumably you're referring to the version of the OpenSSL FOM, since OpenSSL itself went from 1.1.1 to 3.0. FOM 2.0.16 was completed before SP800-56A Rev.3 was published, so obviously it doesn't meet the Rev.3 specification. So the curves which are allowed in FIPS mode are different - and in particular, more restricted - in OpenSSL than they would be if it followed Rev.3. > Which all functions that affects. All of the ECDH ones, in FIPS mode, since it affects which curves are allowed. Outside of FIPS mode, it's irrelevant. The OpenSSL FOM's validation has historical status anyway, so I don't see the lack of SP800-56A Rev.3 compliance as making much of a difference in terms of validation. I suppose it might create issues for interoperability, if a peer system using a different implementation in FIPS mode insisted on using a curve allowed by Rev.3 but not by earlier SP800-56A revisions. But I generally don't work with FIPS mode. -- Michael Wojcik
