SP 800-227 is published

[dustin...@nist.gov]

All,

NIST has published the final version of Special Publication (SP) 800-227, Recommendations for Key-Encapsulation Mechanisms. A key-encapsulation mechanism (KEM) is a set of algorithms that can be used by two parties under certain conditions to securely establish a shared secret key over a public channel. This publication describes the basic definitions, properties, and applications of KEMs and provides recommendations for implementing and using KEMs securely.

NIST greatly appreciates all the feedback and discussion and has incorporated several updates to SP 800-227 based on the comments received. The public comment period on the initial public draft (IPD) was open through March 7, 2025, and the feedback received is now linked from the SP 800-227 publication details. NIST also held a virtual Workshop on Guidance for KEMs on February 25-26, 2025, to gather additional input on SP 800-227. Presentations and the recording of the workshop are available on the event web page.

Dustin Moody

NIST PQC

[And a reminder that the 6th NIST PQC Standardization Conference is next week]

[niux_d...@icloud.com]

Typo at the Appendix A List of Acronyms:

ML-KEM is Module-Lattice Key Encapsulation Mechanism, not Modular-Lattice-....

I too made that mistake, but the lattice is based on 'Module', which is an algebraic structure.

Hope this can be a "last-minute".

Thanks.

--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/55c220e9-91c0-4889-91e3-c94c820f7467n%40list.nist.gov.

[John Mattsson]

Hi,

 

I really like SP 800-227, big thanks for all the work on this! And good that FIPS 203 already refer to SP 800-227 for requirements when using ML-KEM in applications.

 

I plan to review the full document in detail at a later point.

 

Ericsson already refered to the Key Combiner in SP 800-227 for our contribution to 3GPP

https://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_124_Wuhan/Docs/S3-253492.zip

 

"A well-constructed composite KEM C[Π1, Π2] should preserve the security properties of its component KEMs Π1 and Π2. This crucially depends on how the composite KEM is constructed and the choice of the key combiner."

"Therefore, NIST encourages the use of key combiners that generically preserve IND-CCA security"

 

I think this guidance makes sense as long as IND-CPA KEMs, like RSA-KEM and ECDH-KEM, are allowed, an IND-CPA PQ/T hybrid KEM would not be weaker than other approved options.

 

However, when RSA and ECC are no longer allowed in 2035 and only IND-CCA2 KEMs like ML-KEM and HQC-KEM remain, I believe this guidance is too permissive. NIST should clarify that after 2035, a key combiner that preserves the IND-CCA2 security of ML-KEM shall be used. At that point, PQ/T hybrids that weaken the security of ML-KEM or HQC-KEM to IND-CPA should be disallowed.

 

Similarly, I think NIST should provide equivalent guidance for hybrid signatures. Like KEMs, PQ/T hybrids offering only EUF-CMA security are acceptable while RSASSA-PKCS1-v1_5 or ECDSA are allowed. However, after 2035, PQ/T hybrid constructions that weaken the SUF-CMA security of ML-DSA should no longer be permitted. NIST should make it clear that after 2035, ML-DSA hybrid constructions must preserve SUF-CMA security.

 

Cheers,

John

 

--

[Bas Westerbaan]

Similarly, I think NIST should provide equivalent guidance for hybrid signatures. Like KEMs, PQ/T hybrids offering only EUF-CMA security are acceptable while RSASSA-PKCS1-v1_5 or ECDSA are allowed. However, after 2035, PQ/T hybrid constructions that weaken the SUF-CMA security of ML-DSA should no longer be permitted. NIST should make it clear that after 2035, ML-DSA hybrid constructions must preserve SUF-CMA security.

What construction do you have in mind?

To preserve SUF-CMA security of both components, on signing, you can generate a WOTS keypair and use as signature

  Sign_MLDSA(pk_WOTS || M) || Sign_Trad(pk_WOTS || M) || Sign_WOTS( Sign_MLDSA(pk_WOTS || M) || Sign_Trad(pk_WOTS || M) )

With w=256 that adds about 300 bytes to the signature plus a not insignificant amount of hashing. Although I'd love combiners to be SUF-CMA robust by default, this seems too expensive.

Perhaps you were suggesting only achieving SUF-CMA if ML-DSA is not broken. For instance, that'd be achieved by using as signature

  Sign_Trad(M) || Sign_MLDSA(Sign_Trad(M) || M)

This begs the question: if you have a use case where SUF-CMA is critical for security, but relying completely on ML-DSA is fine, then why bother with the traditional component? From a compliance perspective an argument for making the other component load-bearing can be made: despite adding ML-DSA, the traditional (and already verified) component will still ensure SUF-CMA today.

Worst outcome here would be that we end up with three different variants of each ML-DSA hybrid: one for each of the constructions just discussed.

I'd say the best of the unfortunate choices is to have protocols only assume EUF-CMA. Still I'd like all future NIST signature schemes to achieve SUF-CMA.

Best,

 Bas

[John Mattsson]

>Although I'd love combiners to be SUF-CMA robust by default, this seems too expensive.

 

This appears to be a very active research area. I was happy to see the “Bird of Prey” paper appear just two days after I posted on PQUIP about the lack of SUF-CMA hybrids :) I haven’t had time to read it in detail yet, but judging from the figures, the constructions don’t look too heavy. Would be nice if someone have more exact performance figures.

https://eprint.iacr.org/2025/1844.pdf

 

>Perhaps you were suggesting only achieving SUF-CMA if ML-DSA is not broken.

 

Yes, for PQ/T hybrids, I think that is the relevant measure after 2035.

 

• Pre-2024: PQC not standardized and should be seen as contributing zero security. Security relies on Traditional. Important that the hybrid does not weaken the security of Traditional.

 

• 2024-2035: It's complicated

 

• Post-2035: Traditional disallowed and should be seen as contributing zero security. Security relies on PQC. Important that the hybrid does not weaken the security of PQC.

 

> if you have a use case where SUF-CMA is critical for security

 

My assumption is that many developers will not understand that SUF-CMA is critical for security but will assume that any hybrid automatically provides better security. If ML-DSA remains strong, which seems likely, we risk deployments where EUF-CMA PQ/T hybrids with ML-DSA end up reducing overall security rather than improving it.

 

>Worst outcome here would be that we end up with three different variants of each ML-DSA hybrid: one for each of the constructions just discussed.

 

It’s hard to say what the worst outcome would be, but I think standardizing EUF-CMA hybrids of ML-DSA for general use, and continuing to use them beyond 2035, would be a bad outcome.

 

>I'd say the best of the unfortunate choices is to have protocols only assume EUF-CMA.

 

I think a lot of developers instinctively treat RSASSA-PKCS1-v1_5 and ECDSA as SUF-CMA, even if they don’t know what SUF-CMA is. And even if you tell them to assume EUF-CMA, I think they would often implement protocols incorrectly anyway.

 

National security systems and other high-security applications can manage length-extension attacks, EUF-CMA, and point validation, as experts carefully control every aspect of the implementation. Unfortunately, this is not always the case in enterprise and industrial scenarios. It’s quite common for proprietary and open-source implementations, and even other SDOs, to not fully adhere to all requirements specified in NIST specifications.

 

>Still I'd like all future NIST signature schemes to achieve SUF-CMA.

I agree with that.

 

Cheers,

John