CNSA and SHA3-256 usage within IETF's HPKE

[Jeff Andersen]

Hello,

My team is working on implementing an IETF standard: RFC 9180, Hybrid Public Key Encryption. The "hybrid" in the name refers to the notion that the spec ties together key-encapsulation mechanisms and symmetric encryption.

We are targeting both classical and hybrid-PQ algorithms. The base RFC 9180 specification provides code-points for classical KEMs. https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hybrid-kems is a stable IETF draft that provides code-points for hybrid-PQ KEMs. To satisfy CNSA 2.0 we are implementing the "QSF-KEM(ML-KEM-1024,P-384)-XOF(SHAKE256)-KDF(SHA3-256)" code point, which targets ML-KEM-1024.

That algorithm internally invokes SHA3-256. The CNSA 2.0 FAQ states:

• NSA has not approved SHA-3 as a general purpose hash algorithm. Its use is strictly limited to those cases where it is prescribed by the standard describing an NSA-approved algorithm, such as LMS within NIST SP 800-208, or for [part of a system’s integrity-checking process, such as secure boot.]
• Using SHA-3 or SHAKE outside those narrowly defined applications where it is completely self-contained, such as when called within an algorithm function, significantly increases the interoperability testing burden and breaks many use cases for CNSA 2.0.

Taken together, I believe that SHA3-256's use within HPKE is compliant with CNSA 2.0, as this is not being deployed as a general-use hash algorithm; rather, it is called within an algorithm function, namely the HPKE Decaps() method for the PQC code-point described above.

I understand that this is more a question for NSA than NIST. I've sent this request to NSACryp...@nsa.gov but have not yet received a reply, so I thought I'd post here to get more eyes on it.

Regards,

--Jeff Andersen

[Deirdre Connolly]

> https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hybrid-kems

I wouldn't call this stable, new versions are dropping by next week in time for the IETF 123 document deadline: 

https://github.com/cfrg/draft-irtf-cfrg-concrete-hybrid-kems
https://github.com/cfrg/draft-irtf-cfrg-hybrid-kems/

CFRG documents will no longer be registering codepoints for HPKE, those are being handled now by the new HPKE WG (https://datatracker.ietf.org/group/hpke/about/, https://datatracker.ietf.org/doc/draft-ietf-hpke-pq/)

CNSA 2.0 also discourages hybrid PQ solutions except for exceptions, I'm willing to bet a nickel they are happy to use ML-KEM-1024 vs a hybrid KEM in HPKE (which is already registered in IANA for use in HPKE and being updated in the aforementioned https://www.ietf.org/archive/id/draft-ietf-hpke-pq-00.html#name-iana-considerations)

--
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/CADRsRuWi%3DYMtcO0Qv5Xd6yLyTu7cKDsadH36H8qkh%2Bo_k5tCww%40mail.gmail.com.

[Jeff Andersen]

That would be an option, yes. However, that would require a new IETF draft and code point. I'm hoping I can implement the draft that's already out there, instead of adding a new one to the mix.

--Jeff Andersen

On Mon, Jun 30, 2025 at 9:27 AM Stephan Mueller <smue...@chronox.de> wrote:

Am Montag, 30. Juni 2025, 17:49:18 Mitteleuropäische Sommerzeit schrieb 'Jeff
Andersen' via pqc-forum:

Hi Jeff,

> Hello,
>
> My team is working on implementing an IETF standard: RFC 9180

> <https://datatracker.ietf.org/doc/rfc9180/>, Hybrid Public Key Encryption.

> The "hybrid" in the name refers to the notion that the spec ties together
> key-encapsulation mechanisms and symmetric encryption.
>
> We are targeting both classical and hybrid-PQ algorithms. The base RFC 9180
> specification provides code-points for classical KEMs.
> https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hybrid-kems is a
> stable IETF draft that provides code-points for hybrid-PQ KEMs. To satisfy
> CNSA 2.0 we are implementing the "
> QSF-KEM(ML-KEM-1024,P-384)-XOF(SHAKE256)-KDF(SHA3-256)

> <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hybrid-kems#name-qsf-> kemml-kem-1024p-384-xof>" code point, which targets ML-KEM-1024.

Instead of using SHAKE, why not using KMAC, an algorithm allowed in SP800-108
as a KDF operation? This should cover all concerns you may have with CNSA2.0.

Looking at recent PPs with CNSA2.0 compliance [1], we see:

- ML-KEM allowed

- ECDH P-384 allowed

- Reference to SP800-56A rev3 given for deriving key material

- SP800-56A rev3 refers in section 5.8 to section SP800-56C for the KDFs

- SP800-56C rev1 chapter 2 bullet 2 refers to SP800-108

- SP800-108 allows the use of KMAC (not the KMACXOF!) where the difference
between KMAC and KMACXOF is only that for KMAC you must know a-priori the
amount of data to be generated (i.e. you cannot "squeeze out" the bits as
needed).

Therefore, you have a SHAKE-equivalent that is approved to my reading.

That is also the reason why [2] specifies KMAC instead of anything else.

[1] https://www.niap-ccevs.org/protectionprofiles/516

[2] https://leancrypto.org/papers/KyberIES_specification.pdf

Ciao
Stephan

[Stephan Mueller]

Am Montag, 30. Juni 2025, 17:49:18 Mitteleuropäische Sommerzeit schrieb 'Jeff
Andersen' via pqc-forum:

Hi Jeff,

> Hello,
>
> My team is working on implementing an IETF standard: RFC 9180

> <https://datatracker.ietf.org/doc/rfc9180/>, Hybrid Public Key Encryption.

> The "hybrid" in the name refers to the notion that the spec ties together
> key-encapsulation mechanisms and symmetric encryption.
>
> We are targeting both classical and hybrid-PQ algorithms. The base RFC 9180
> specification provides code-points for classical KEMs.
> https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hybrid-kems is a
> stable IETF draft that provides code-points for hybrid-PQ KEMs. To satisfy
> CNSA 2.0 we are implementing the "
> QSF-KEM(ML-KEM-1024,P-384)-XOF(SHAKE256)-KDF(SHA3-256)

> <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hybrid-kems#name-qsf-> kemml-kem-1024p-384-xof>" code point, which targets ML-KEM-1024.

[Blumenthal, Uri - 0553 - MITLL]

No, it would not be an option, because CNSA-2.0 does not allow all the NIST standards - only those explicitly listed. 

E.g., MK-KEM-1024, but not ML-KEM-768. 

—

Regards,

Uri

Secure Resilient Systems and Technologies

MIT Lincoln Laboratory

On Jul 1, 2025, at 07:59, 'Jeff Andersen' via pqc-forum <pqc-...@list.nist.gov> wrote:



That would be an option, yes. However, that would require a new IETF draft and code point. I'm hoping I can implement the draft that's already out there, instead of adding a new one to the mix. --Jeff Andersen On Mon, Jun 30, 2025 at

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside the Laboratory.

 

ZjQcmQRYFpfptBannerEnd

--
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/CADRsRuVW_u6UtgocFBiWK%3Dc7Ym3be1mCPoWUry7hH_j1yW12Aw%40mail.gmail.com.

[Christopher Swenson]

I don't think CNSA 2.0 has an opinion on KMAC. It also doesn't list HMAC, which is almost certainly allowed.

In any case, I think either KMAC or HMAC or SHA3-256 could fall under "Using SHA-3 or SHAKE [in] those narrowly defined applications where it is completely self-contained", which is allowed?

Since SHAK256, KMAC, HMAC, or SHA3-256 would be used as an XOF or KDF as part of QSF-KEM(ML-KEM-1024,P-384)-XOF(SHAKE256)-KDF(SHA3-256), then I'd guess that would be "completely self-contained", since it is internal to the larger algorithm. Though the CNSA also implies that the larger algorithm should be CNSA-approved, which HPKE / QSF-KEM(*)-XOF(*)-KDF(*) is not.

It's a murky area to be sure.

(Side note, we need a better name for the "QSF-KEM(*)-XOF(*)-KDF(*)" hybrid modes, a.k.a., Hybrid Hybrid Public Key Encryption

• Double Hybrid PKE
• HHPKE
• H2PKE
• 2 Hybrid 2 Public Key Encryption (2H2PKE)

I prefer H2PKE personally.)

--Christopher

------

Christopher Swenson
[he/him]
Principal Firmware Engineer
Azure Systems Planning and Architecture
chsw...@microsoft.com

---

From: pqc-...@list.nist.gov on behalf of Blumenthal, Uri - 0553 - MITLL
Sent: Tuesday, July 1, 2025 5:52 AM
To: Jeff Andersen
Cc: Stephan Mueller; pqc-forum
Subject: [EXTERNAL] Re: [EXT] Re: [pqc-forum] CNSA and SHA3-256 usage within IETF's HPKE

No, it would not be an option, because CNSA-2.0 does not allow all the NIST standards - only those explicitly listed. 

E.g., MK-KEM-1024, but not ML-KEM-768. 

—

Regards,

Uri

Secure Resilient Systems and Technologies

MIT Lincoln Laboratory

On Jul 1, 2025, at 07:59, 'Jeff Andersen' via pqc-forum <pqc-...@list.nist.gov> wrote:



This Message Is From an External Sender

This message came from outside the Laboratory.

 

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/4F4F690B-F66A-4882-84E4-A58430E6FA42%40ll.mit.edu.