SP800-56A REV3

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

SP800-56A REV3

Nagarjun J
Hi ,

What is this SP800-56A REV3 new FIPS requirement,  How it affects ECDH , how it is different from  openssl-2.0.16 ECDH implication. Which all functions that affects.

Regards
Nagarjun


Reply | Threaded
Open this post in threaded view
|

RE: SP800-56A REV3

Michael Wojcik
> From: openssl-users <[hidden email]> 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