OpenSSL Communities
Wed 18 Jun 2025 11:33AM

Enabling hybrid key exchange in FIPS mode for old FIPS providers

AA Anton Arapov Public Seen by 65

Cross-post from Distributions; Thread by @Dmitry Belyavsky:

OpenSSL 3.5 has enabled hybrid PQ key exchange with the new FIPS provider.

It's a great result but distributions (and I presume, big corporations) rely on previously certified versions of FIPS provider (e.g. 3.1 for upstream, 3.0.7 for RHEL).

According to a set of NIST documents (800-56Ar3) we can treat MLKEM as auxiliary data for EC key exchange.

Different orderings of the component data fields of FixedInfo may be used, and one or more of

the data fields may be combined (or omitted under certain circumstances). See Section 5 in SP

800-56C, and Sections 5, 7.4, 7.5 and 7.6 in SP 800-108 for details


We (Red Hat) has provided a proof-of-concept patch that works for our purpose and enables Hybrid kex in FIPS mode. It look a bit hackerish but resolves several obstacles:

  • pass propq down when generating MLKEM keys, so SHAKE would be fetched from default provider. Otherwise FIPS 3.0 provider doesn't have squeeze method before 3.2 (not certified upstream)

  • Expand EC pubkey when old (< 3.0.8) FIPS provider returns compressed one. We in RHEL have 3.0.7 so we came across this problem. I think it's acceptable upstream


I would like to see if this approach is of interest to the communities I represent (Distributions) or am involved in (Big corps)

JJ

Jeff Johnson Wed 18 Jun 2025 1:22PM

@Dmitry Belyavsky we have enabled hybrid kex in FIPS mode internally. This is a way to keep FIPS capable products until FIPS PQ algs in a module are approved. However, it should be noted that NIAP and Common Criteria do not like nor accept hybrid kex. Typically, those requirements were subsets of FIPS so FIPS "mode" was required prior to Common Criteria restrictions being enabled (a CC mode). Their preference for pure PQ algs has changed the way to approach that. Basically, you cannot use hybrid kex to meet NIAP/CC requirements (and hence not FIPS hybrid) and there are no modules yet that have pure PQ algs. So...... what do they do. Those orgs have conceded that in the meantime they will accept ACVP alg certs listed on NIST/CMVP websites as an interim solution. Lots of fun during this transtion! 馃檪

CB

Chris Brych Fri 20 Jun 2025 1:09PM

Oracle supports Red Hat's idea that enables hybrid KEX in FIPS mode.

DJL

Dimitri John Ledkov Fri 25 Jul 2025 3:28PM

Chainguard will support this interop too, and will also push for NIST resolution to approve this. We are looking to enable and test this interop across Go, Java, C implementations based on OpenSSL, Sun, Bouncycastle implementations within chainguard's implementations, as well as rhel and oracle products.

@ANUBHAV however hackish the patch, are you willing or interested to share it with me? the version numbers do not apply to stuff that Chaingaurd ships, and I would want to upstream something that allows to build extra providers which might make things work.

DJL

Dimitri John Ledkov Fri 25 Jul 2025 3:29PM

Note Keyfactor has developed Bouncycastle providers for Hybrid KEM that can be mixed/matches in a way to enable Hybrid KEM in such certification contexts too.

PD

Paul Dale Sun 27 Jul 2025 9:40PM

The proposed patch is: https://github.com/openssl/openssl/pull/27728

I understand that an alternative approach is being prototyped.

The big problem with including a "hacky" patch is that it then has to be supported by the project for many years going forward. This is often a lot more painful than the (relatively) short transition period.

DJL

Dimitri John Ledkov Fri 1 Aug 2025 2:09PM

@Anton Arapov @Chris Brych just to be clear, the consensus here is to attempt to deliver Hybrid PQC that uses validated EC-DSA with ML-KEM right? And that explicitely no attempts to support Hybrid PQC that uses X25519 should be done - especially given the very direct statement about it at https://csrc.nist.gov/news/2025/proposal-for-sp-800-56-reports

There are currently over 30+ OpenSSL validated provider modules which offer X25519 in approved mode by accident, or intentionally, under both FIPS 140-2 and FIPS 140-3, which to me is a gross mistake. (some of them claim that successful operation identical to all approved usage - is indicator of unapproved usage)

AK

Alicja Kario Thu 7 Aug 2025 9:42AM

just to be clear, the consensus here is to attempt to deliver Hybrid PQC that uses validated EC-DSA with ML-KEM right? And that explicitely no attempts to support Hybrid PQC that uses X25519 should be done

yes, x25519mlkem768 is not FIPS approved without FIPS approved ML-KEM-768; secp256r1mlkem768 and secp384r1mlkem1024 will be FIPS approved with a secp256r1 or secp384r1 coming from a FIPS certified module

CB

Chris Brych Tue 12 Aug 2025 4:12PM

Sorry for the delayed response to this thread as I was away on vacation but the NIST CTG group are planning to release an update to NIST SP 800-5a6Cr2 and publish NIST SP 800-227 that will allow the use of X-wing as a construct as part of a hybrid PQ key exchange. The problem is that as much as industry needs this now, the current FIPS 140-3 standard and accompanying IG's do not allow this today. I have been following CMUF discussions on whether this will be allowed in the interim and the CMVP have not committed to allowing its use until the standards are finalized. The indication seems to be that it shouldn't be too much longer....stay tuned.