Updates to the CNSA 2.0 FAQ

[Stern, Morgan B]

With the publication of NIST's first post quantum standards, NSA has updated our guidance on our Commercial National Security Algorithm Suite 2.0 (CNSA 2.0):
https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/1/CSI_CNSA_2.0_FAQ_.PDF

The new FAQ answers several questions that have arisen as customers implement and deploy CNSA 2.0, some of which came from discussions on this group. New information includes:

-Listing the NIST standards documents that define CNSA 2.0 suite of algorithms and updated timelines for transitions
-Clarification on which NIST signatures from the recent standards are allowed for use in NSS
-Allowance of additional options in internal hardware checks, such as boot-up integrity checks
-Added context on our views on hybrid systems

Looking forward to continued community engagement. Thanks for the questions over the last year.

Morgan Stern
NSA Cybersecurity

[Markku-Juhani O. Saarinen]

Thanks Morgan,

Some further questions related to the use of SHA384 and SHA512:

With my reading of FIPS 204, HashML-DSA is the only standards-compliant and FIPS-certifiable way of using SHA2-384 or SHA2-512 with ML-DSA. However, HashML-DSA is now explicitly disallowed in CNSA 2.0 (FAQ v2.1 pg 9), and SHAKE256 is also not allowed. The table on Page 3 states that "SHA3-384 or SHA3-512 allowed for internal hardware functionality only (e.g., boot-up integrity checks.)

Note that ("pure") ML-DSA  -- Algorithms 1,2,3 in the final FIPS 204 -- does not use either SHA2 or SHA3 for anything; just SHAKE128 and SHAKE256.

SHA3 is also not used by any of the NIST (SP 800-208) parameter sets of LMS (just SHA2-256 and SHAKE). ML-KEM has an internal technical use for SHA3, but that's indeed "internal".

Anyway, if NSA wants modules that use SHA2 (-384 and/or -512) to compute digests for ML-DSA with some method not specified in FIPS 204, the NSA should specify a preferred method. Earlier versions of ML-DSA (like the "initial public draft" -- IPD) allowed one to simply use a SHA2 digest to generate a signature, but that option is no longer present in FIPS 204.

Background: The FAQ states that HashML-DSA was introduced to "prevent a vulnerability in the case of key re-use." I don't think this was the reason -- and I doubt HashML-DSA fixes such problems. HashML-DSA (and the explicit domain separation in ML-DSA itself) in the final FIPS 204 allows it to regain "existential unforgeability" properties. In the initial draft version of FIPS 204, the same signature (not keys) could be alternatively interpreted as a signature of a 512-bit message M1 or the hash result of SHA2-512(M2); trivially, for any M2, one could find M1, M1 != M2 with the same signature. The interpretation (compute an extra hash or not?) was basically left to unauthenticated metadata. Albeit not always problematic in practice, this violated the EUF-CMA security property that NIST (and most cryptographers) has used to define a secure digital signature scheme since the start of the PQC standardization process.

Cheers,

-markku

Dr. Markku-Juhani O. Saarinen <mj...@iki.fi>

--
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/f045346e94fe4536a015dd09a062bdae%40nsa.gov.

[bruno]

Thanks Morgan. Markku

I did not want to comment this morning since :

1. The URL of the v2.0 FAQ (labeled 2.01 December 2024) render the same domc that the PDF From: 'Stern, Morgan B' via pqc-forum <pqc-...@list.nist.gov>
   Date: Thursday, 18 April 2024 at 21:03.  (Sydney Time) Then i have not been able to compute the difference.
2. I suspected this morning to spot that SHA-256 suppression (not the rest outline in Markku's email) that is also in my country disallowed by Cyber/ASD [1]. I am not sure it is new or if did not spot it earlier. I am getting confused now with the hashing in all contexts...
   

If anyone can outline or spot the difference in the NSA FAQ v2.0 and v2.01 and is in the same situation them we should correct. May be it is me?

[1] https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/ism/cyber-security-guidelines/guidelines-cryptography

PS: Please forget that if i am mistaking

B.

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CA%2BiU_q%3DoYz0LxBiU2CESUJpLejQ_w-3nH9S2F3EOjNuq8s_U2Q%40mail.gmail.com.

[John Mattsson]

Thanks Morgan for the info on the updated FAQ,

 

- Very good news that CNSA 2.0 now allows SHA-3 for specific applications. While there is no need to replace SHA-2 in existing deployments, I think all new standards and systems should use of SHA-3, which is superior both theoretically (random oracle) and in implementations (side-channels).

 

- Thanks for the update on HashML-DSA, we tend to agree with "Because HashML-DSA does not offer any functionality not already offered by the CNSA hash functions combined in a standard way with ML-DSA-87, and because standard ML-DSA-87 is expected to be widely supported, NSA anticipates there will be no need for HashML-DSA in NSS." HashML-DSA is causing a lot of complexity and confusion.

 

As Marko says, if NSA wants modules that use SHA-384 to compute a message for use with ML-DSA.Sign(), i.e., not ML-DSA.Sign_internal(), NSA should should specify a preferred method.

 

- Is there a public version of "The 2024 update to CNSSP 15" available? The only document I find on cnss.gov is from 2016/.

https://www.cnss.gov/CNSS/issuances/Policies.cfm

The document "Announcing the Commercial National Algorithm Suite 2.0", which NSA refers to is no longer available

https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/3148990/nsa-releases-future-quantum-resistant-qr-algorithm-requirements-for-national-se/

 

Cheers,

John

[John Mattsson]

Sophie Schmieg has written a blog post "HashML-DSA considered harmful" which is well worth reading. I think Ericsson agrees with most of what Sophie says including "We would be best off by ignoring the existence of the HashML-DSA/HashSLH-DSA variants completely".

https://keymaterial.net/2024/11/05/hashml-dsa-considered-harmful/

Cheers,
John

 

--

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/GVXPR07MB9678CBE8EB3273FB6227D5D589182%40GVXPR07MB9678.eurprd07.prod.outlook.com.

[Blumenthal, Uri - 0553 - MITLL]

Some further questions related to the use of SHA384 and SHA512:

 

I’m not Morgan 😉, but

With my reading of FIPS 204, HashML-DSA is the only standards-compliant and FIPS-certifiable way of using SHA2-384 or SHA2-512 with ML-DSA.

 

I don’t see it this way at all:

 

• FIPS 204 allows (defines) “pure” ML-DSA;
• ML-DSA does not care what it is signing;
• ML-DSA input may well be a SHA-512 hash of a file you want signed.

 

Note that ("pure") ML-DSA  -- Algorithms 1,2,3 in the final FIPS 204 -- does not use either SHA2 or SHA3 for anything; just SHAKE128 and SHAKE256.

 

Of course! How you “prepare” the input for ML-DSA is 100% your business. CNSA-2.0 allows using SHA-314 and SHA-512 in that “preparation” process, but not SHA3. So…?

 

Anyway, if NSA wants modules that use SHA2 (-384 and/or -512) to compute digests for ML-DSA with some method not specified in FIPS 204, the NSA should specify a preferred method. Earlier versions of ML-DSA (like the "initial public draft" -- IPD) allowed one to simply use a SHA2 digest to generate a signature, but that option is no longer present in FIPS 204.

 

Hmm… I think NSA did specify their “preferred method”, and it happens to be FIPS-180-4, SHA-384 or SHA-512 (page 3 of the published CNSA-2.0 FAQ).  

 

What more would you want, and why?

 

Thanks!

 

On Tue, Jan 14, 2025 at 12:01 AM 'Stern, Morgan B' via pqc-forum <pqc-...@list.nist.gov> wrote:

With the publication of NIST's first post quantum standards, NSA has updated our guidance on our Commercial National Security Algorithm Suite 2.0 (CNSA 2.0):
https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/1/CSI_CNSA_2.0_FAQ_.PDF

The new FAQ answers several questions that have arisen as customers implement and deploy CNSA 2.0, some of which came from discussions on this group. New information includes:

-Listing the NIST standards documents that define CNSA 2.0 suite of algorithms and updated timelines for transitions
-Clarification on which NIST signatures from the recent standards are allowed for use in NSS
-Allowance of additional options in internal hardware checks, such as boot-up integrity checks
-Added context on our views on hybrid systems

Looking forward to continued community engagement. Thanks for the questions over the last year.

Morgan Stern
NSA Cybersecurity

--
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/f045346e94fe4536a015dd09a062bdae%40nsa.gov.

--
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/CA%2BiU_q%3DoYz0LxBiU2CESUJpLejQ_w-3nH9S2F3EOjNuq8s_U2Q%40mail.gmail.com.

[Markku-Juhani O. Saarinen]

On Tuesday, January 14, 2025 at 6:02:44 PM UTC+2 Blumenthal, Uri - 0553 - MITLL wrote:

Anyway, if NSA wants modules that use SHA2 (-384 and/or -512) to compute digests for ML-DSA with some method not specified in FIPS 204, the NSA should specify a preferred method. Earlier versions of ML-DSA (like the "initial public draft" -- IPD) allowed one to simply use a SHA2 digest to generate a signature, but that option is no longer present in FIPS 204.

Hmm… I think NSA did specify their “preferred method”, and it happens to be FIPS-180-4, SHA-384 or SHA-512 (page 3 of the published CNSA-2.0 FAQ). 

Hi Uri,

I actually suspect that CMS might be the preferred method. This would be the "application layer" which is allowed by Section 5.4 of FIPS 204. Passing just a raw hash wouldn't really constitute an "application layer" that contains "additional attributes" as discussed in FIPS 204.

Cheers,

- markku

[COSTA Graham]

THALES GROUP LIMITED DISTRIBUTION to email recipients

Subject: Clarification on SHA-3 Use in Firmware Updates

Hi Morgan,

Are we correct in interpreting the updates as permitting SHA-3 to be used as part of a firmware update mechanism for a module? For example, could it be implemented in a manner similar to CMS, with a SHA-3 hash of the update package followed by an ML-DSA-87 signature of that hash?

We believe this is the case, given that this mechanism is 'internal to the vendor environment' and is linked to supporting module integrity.

Slightly off topic for this list, but as an independent follow-on: Is the NSA intending to allow SHA-3 to be used with the SP 800-90 series Random Bit Generators? Specifically, will it be a permitted algorithm for use within these RBGs? This wouldn't impact interoperability, but it is noted in the CNSA 2.0 FAQ that 'system integrity' is exclusively cited as an example for the permitted use of SHA-3.

Our motivations for using SHA-3 over SHA-2 with DRBG are, as mentioned by others, performance and the mitigation of certain side-channel risks.

Any clarifications you can provide would be much appreciated to help reduce implementation risk.

Kind regards,

Graham
Thales.

[Sophie Schmieg]

There is a second way to prehash ML-DSA, and while I am not Morgan, I would not conclude that this method is off limits in my reading of CNSA2. Using the comment on line 6, algorithm 7, you can conclude that you are allowed to compute µ = SHAKE256(SHAKE256(pk, 64) || 0x00 || 0x00 || m, 64) on a different machine, in a different FIPS module (e.g. a software library) and then send µ over the wire to the holder of the actual private key (e.g. an HSM). This is not using SHAKE256 as a hash function, but a multi-party computation of ML-DSA, split between two machines, in a way specifically allowed within the NIST specification, and generic use of SHA3 would still be non-compliant.

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/PAZP264MB4063E3E4051AD514BD4FAF5099182%40PAZP264MB4063.FRAP264.PROD.OUTLOOK.COM.

--

Sophie Schmieg | Information Security Engineer | ISE Crypto | ssch...@google.com

[COSTA Graham]

THALES GROUP LIMITED DISTRIBUTION to email recipients

 

Thank you Sophie.  That is understood.  Our primary question for Morgan is as to permitted use-case for SHA-3.

 

i.e. In the case of valid use-cases for SHA3 with the permitted signature algorithm, were they intending to allow use exclusively for secure boot or would use with a firmware update mechanisms also be permitted.

[Falko Strenzke]

I have a question to NSA regarding the cases where SHA3 usage is allowed in NSS systems. In the FAQ section we find the statements

"No, neither SHA-3 nor SHAKE are approved for use in CNSA 2.0 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 [...] ".

My question is whether a KEM combiner following the design criteria specified in SP 800-227 and thereby using a SHA3-based KDF counts as an NSA approved algorithm.

Falko

Am 13.01.25 um 23:00 schrieb 'Stern, Morgan B' via pqc-forum:

--

MTG AG
Dr. Falko Strenzke

Phone: +49 6151 8000 24
E-Mail: falko.s...@mtg.de
Web: mtg.de

---

MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany
Commercial register: HRB 8901
Register Court: Amtsgericht Darmstadt
Management Board: Jürgen Ruf (CEO), Tamer Kemeröz
Chairman of the Supervisory Board: Dr. Thomas Milde

This email may contain confidential and/or privileged information. If you are not the correct recipient or have received this email in error,
please inform the sender immediately and delete this email.Unauthorised copying or distribution of this email is not permitted.

Data protection information: Privacy policy

[Petr Muzikant]

Hello Morgan,

I sent an email to NSACryp...@nsa.gov (i.e. email listed at the end of CNSA2.0 FAQ) some time ago with a question but so far didn't get the answer. I might try my luck here:

I am writing to inquire about the classification of legal document signing procedures that adhere to acts such as the E-Sign Act and the Uniform Electronic Transactions Act (UETA). Specifically, I would like to understand how these signing processes align with the six categories outlined in the CNSA2.0 timeframe.

Could you please confirm whether the usage of public-key algorithms, in this context, falls within the regulatory space defined by CNSA2.0? If so, could you kindly specify into which category it belongs?

Thank you for your time and assistance.

Sincerely,

Petr Muzikant, Cybernetica AS.

[Mike Ounsworth]

Falko,

 

I do not represent the NSA, but we have this statement from Deb Cooley during IETF PQUIP 118 (time = 1:34:15) saying that that there is a good install base of SHA2, but wide deployment of hardware with SHA3 support will not happen any time soon, so they want crypto protocols to continue using SHA2 where possible.

 

Recording of Deb’s comments at PQUIP 118:

https://youtu.be/W46QrMvlLZU?si=ni-Z5EYEDTTyNgkd&t=5653

 

So I guess the answer to your question will depend on how the hybrid combined KEM is implemented – if the hybrid is delivered as one atomic module with both component algorithms and the combiner buried inside then it probably doesn’t matter, but if the hybrid is delivered as one ECC module, one ML-KEM module, and an external combiner, then this probably is easier to deploy on current hardware if it has a SHA2-based combiner.

 

Again, I do not represent the NSA. I am just piecing together things I have heard in various public forums.

 

---

Mike Ounsworth

--

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/1830b5bb-ed24-4b9d-bd75-cfd469a78257%40mtg.de.

[Brent Kimberley]

Worse is better. 

SHA3 cores are more responsive, yield higher throughput, and consume less joules per symbol.

10.1016/j.micpro.2020.103444

---

From: 'Mike Ounsworth' via pqc-forum <pqc-...@list.nist.gov>
Sent: Wednesday, January 22, 2025 9:55 AM
To: Falko Strenzke <falko.s...@mtg.de>; Stern, Morgan B <mbs...@nsa.gov>; 'pqc-...@list.nist.gov' <pqc-...@list.nist.gov>
Subject: RE: [EXTERNAL] Re: [pqc-forum] Updates to the CNSA 2.0 FAQ

 

⚠️CAUTION: This email is from an external source. Verify sender before opening links and attachments.⚠️

THIS MESSAGE IS FOR THE USE OF THE INTENDED RECIPIENT(S) ONLY AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, PROPRIETARY, CONFIDENTIAL, AND/OR EXEMPT FROM DISCLOSURE UNDER ANY RELEVANT PRIVACY LEGISLATION. No rights to any privilege have been waived. If you are not the intended recipient, you are hereby notified that any review, re-transmission, dissemination, distribution, copying, conversion to hard copy, taking of action in reliance on or other use of this communication is strictly prohibited. If you are not the intended recipient and have received this message in error, please notify me by return e-mail and delete or destroy all copies of this message.

[John Mattsson]

Yes, I think SHA-3 is superior in almost every way. SHA-2 have significant problems with side-channels, SHA-256 and SHA-512 are vulnerable to length-extension attacks, and SHA-2 does not behave like a random oracle. Ericsson has historically aligned with NSA Suite B and CNSA 1.0, using (HMAC-)SHA-384 whenever possible. As we transition to PQC, Ericsson plans to adopt the superior SHA-3 family as widely as possible.

Ericsson will likely be against any new standards without SHA-3 support. We applaud NIST for mandating the use of SHA-3 in ML-KEM and ML-DSA. Ed448 and X-Wing and some other recent standards that only use SHA-3. Ericsson would like to see as much transition to SHA-3 as fast as possible.

Cheers,
John

 

--

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/YT3PR01MB1054479EDCB670E83F29C5FB8FAE12%40YT3PR01MB10544.CANPRD01.PROD.OUTLOOK.COM.

[Aryeh Archer]

Building off a couple questions from earlier in the thread (from John Mattsson and Graham Costa):

Is there a public version of the 2024 CNSSP 15 that's referenced in the FAQ?
The version on https://www.cnss.gov/CNSS/issuances/Policies.cfm is from 2016, but from the FAQ it sounds like the updated version was published already.

This may be an obvious question, but where can we find a list of which DRBGs are acceptable for CNSA 2.0? And relatedly, is there a reference for entropy source requirements for CNSA 2.0?

Best,

Aryeh

---

From: 'John Mattsson' via pqc-forum <pqc-...@list.nist.gov>
Sent: Wednesday, January 22, 2025 7:31 AM
To: Brent Kimberley <Brent.K...@Durham.ca>; Falko Strenzke <falko.s...@mtg.de>; Stern, Morgan B <mbs...@nsa.gov>; 'pqc-...@list.nist.gov' <pqc-...@list.nist.gov>; Mike Ounsworth <Mike.Ou...@entrust.com>

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/GVXPR07MB9678D4DE13DF932088E3B60689E12%40GVXPR07MB9678.eurprd07.prod.outlook.com.