ML-DSA-87, SHA-384, and CNSA 2.0

[Jeff Andersen]

Scenario: a module currently implements a service that hashes data using SHA-384, and signs the digest M with ECDSA. SHA-384 as a hash algorithm is acceptable for CNSA 2.0, while ECDSA as a signature algorithm is not.

The module wishes to adopt ML-DSA for signing to be compliant with CNSA 2.0. For ML-DSA, CNSA 2.0 mandates "Level V parameters for all classification levels". FIPS 204 denotes ML-DSA-87 as "Category 5".

Question: while adopting ML-DSA-87 for signing M, is the module also required to move away from SHA-384 for generating M? Notwithstanding CNSA 2.0 allowing SHA-384 for hashing?

FIPS 204 section 5.4 describes a mechanism for pre-hashing the message before signing it with ML-DSA. That section states: "In order to maintain the same level of security strength when the content is hashed at the application level or using HashML-DSA, the digest that is signed needs to be generated using an approved hash function or XOF (e.g., from FIPS 180 or FIPS 202) that provides at least 𝜆 bits of classical security strength against both collision and second preimage attacks."

Cross-referencing FIPS 204 section 4 and FIPS 202 section A.1: if one uses ML-DSA-87, pre-hashes may not be generated with SHA-384, but could be generated with SHA-512.

There are a couple possible interpretations:

1. The pre-hash described in FIPS 204 section 5.4 is part of the signature algorithm and bears no relation to the data that is signed, which may be an arbitrary blob. Therefore, it is acceptable to generate M using SHA-384, then pre-hash it using SHA-512, then sign the pre-hash with ML-DSA-87.
   
   This would extend to leveraging IETF draft composite signatures with algorithm ID "id-MLDSA87-ECDSA-P384-SHA512", where M is a SHA-384 digest, M' is a SHA-512 digest, and S1 is an ML-DSA-87 signature.
   
   
2. If ML-DSA-87 is being used to sign a hash, the hash must have been computed with a stronger hash algorithm than SHA-384, such as SHA-512. Otherwise the security strength of ML-DSA-87 would no longer meet level 5 requirements and thus would no longer satisfy CNSA 2.0. As an implication: although CNSA 2.0 nominally allows SHA-384, it effectively does not allow that algorithm if the resulting digest will be signed by ML-DSA.
   
   Taken to its logical conclusion, this would also imply that it is not allowed to use ML-DSA-87 to sign a message M which is a concatenation of multiple digests, where any component digest is computed using SHA-384.

IMO, interpretation #1 is the most imminently sensible. However, I see enough room in the specs for a strict reading to potentially arrive at #2, even though the implications are rather weird.

Interested in others' thoughts.

--Jeff Andersen

[Paul Hoffman]

This message seems to be about CSNA 2.0, not the NIST specs.

On Sep 17, 2024, at 08:59, 'Jeff Andersen' via pqc-forum <pqc-...@list.nist.gov> wrote:

> IMO, interpretation #1 is the most imminently sensible. However, I see enough room in the specs for a strict reading to potentially arrive at #2, even though the implications are rather weird.
>
> Interested in others' thoughts.

These would be questions for the NSA, not NIST. Having said that, if you ask two NSA people how to interpret the CSNA rules, you might get three or more answers.

--Paul Hoffman

[Jeff Andersen]

It seems like a bit of both to me. CNSA 2.0 wants ML-DSA to meet level 5 security strength. I would hope that NIST could answer whether ML-DSA-87.sign(SHA512(M)) where M is computed using SHA384 (either a raw digest or a concatenation of digests) maintains level 5 security strength.

--Jeff Andersen

[Stephan Mueller]

Am Dienstag, 17. September 2024, 10:59:48 GMT-5 schrieb 'Jeff Andersen' via
pqc-forum:

Hi 'Jeff,

> Scenario: a module currently implements a service that hashes data using
> SHA-384, and signs the digest M with ECDSA. SHA-384 as a hash algorithm is
> acceptable for CNSA 2.0

> <https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGOR
> ITHMS_.PDF>, while ECDSA as a signature algorithm is not.

>
> The module wishes to adopt ML-DSA for signing to be compliant with CNSA
> 2.0. For ML-DSA, CNSA 2.0 mandates "Level V parameters for all
> classification levels". FIPS 204 denotes ML-DSA-87 as "Category 5".
>

> *Question*: while adopting ML-DSA-87 for *signing* M, is the module also
> required to move away from SHA-384 for *generating* M? Notwithstanding CNSA

> 2.0 allowing SHA-384 for hashing?

As you said ML-DSA 87 requires a message digest of 512 bits. So, SHA-384 will
not be compliant to FIPS 204.

The hash is used for hashing the message as part of signing. So, when you use
HashML-DSA, you move the hashing of the messge out. As the collision
resistance is called out in FIPS 204, all message hashing aspects should
consider it and thus should apply 2 * lambda.

Therefore, this implies to me that the hashing part that is outside of the
control of HashML-DSA, must comply with the considerations of FIPS 204. Thus,
I see the need that you must use a digest size of 512 bits or larger.


Ciao
Stephan

[Jeff Andersen]

Thanks John, Stephan.

To revise my earlier statement a bit: CNSA 2.0 mandates using level 5 parameters for ML-DSA, which one can certainly do even if the construction effectively gets overall level 4 security by virtue of signing a SHA-384 digest. Which seems to be acceptable to NSA, given their allowance for SHA-384. It does seem like an opinion from NSA would be helpful.

--Jeff Andersen

On Tue, Sep 17, 2024 at 9:54 AM John Preuß Mattsson <john.m...@gmail.com> wrote:

My two cents would be that:

 

“In order to maintain the same level of security strength when the content is hashed at the application level or using HashML-DSA , the digest that is signed needs to be”

 

Does not contain any should/shall/must/recommen and is informative. If you use ML-DSA-87 with SHA-384 you get a security level of 192 bits. As CNSA 2.0 says “Use SHA-384 or SHA-512 for all classification levels.” I would think that it is CNSA 2.0 compliant, but as Paul Hoffman says, you really need to ask NSA.

 

Cheers,

John

[Jeff Andersen]

The implications of NSA not being okay with that construction are quite odd though - they'd allow a module to generate a digest with SHA-384, but have no approved mechanism for signing that digest (or anything derived from it) using a stateless signing algorithm.

--Jeff Andersen

[Brent Kimberley]

To confirm, does SHA512(SHA384(M)) meet or exceed level 5 security strength - for all non-trivial M, where CLZ(M) > exceeds some number such as 512.   Rephrasing the question, If SHA384(M) can be isolated, will the security strength drop to level 4?

---

From: 'Jeff Andersen' via pqc-forum <pqc-...@list.nist.gov>
Sent: Tuesday, September 17, 2024 12:39 PM
To: Paul Hoffman <paul.h...@icann.org>
Cc: pqc-...@list.nist.gov <pqc-...@list.nist.gov>
Subject: Re: [Ext] [pqc-forum] ML-DSA-87, SHA-384, and CNSA 2.0

 

--
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 on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CADRsRuV0E5hJJ-T9iY24JHKjR%3Da0QqsBp9myKdjFFXba49DA6g%40mail.gmail.com.
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.

[Markku-Juhani O. Saarinen]

Hi,

Knowing that it is complicated for NSA folks to put stuff on mailing lists (they do handle direct industry e-mail more easily), let me point everyone to the FAQ instead before you guys flood the mailing list any further.

It says that SHA-512 is acceptable in CNSA 2.0. This was changed fairly recently (in April 2024 version of the FAQ -- they didn't change the URL).

https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF

They don't accept SHAKE256/SHA3 for external hashing, even though ML-DSA obviously uses it internally. When I asked Adrian Stanger (NSA) about this at the SKAW workshop (UCSB/Crypto) last month he said that they don't have "generally anything against SHA-3" but that they're sticking with SHA2 (meaning SHA-384 and SHA-512).

Cheers,

-markku

[Brent Kimberley]

Noted.  Thanks.

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/8704027e-85ad-4f63-a2f2-f80ae7e824fen%40list.nist.gov.

[Scott Fluhrer (sfluhrer)]

I recently attended a presentation by an NSA employee; one note that I took from that presentation was:

 

NSA will specify only the pure (not prehashed) version of ML-DSA

 

Well, hashing the image and then signing that hash is what “prehashing” is.  Hence, from that statement, it would appear that it would not be acceptable to the NSA (and neither would doing an initial hash with SHA-512).

 

One obvious follow-up question is “what use is SHA-384 approved for anyways?”  That, I don’t have a good answer to.

 

It would be nice to get a definitive answer from the NSA, however we all know how likely that is…

 

From: pqc-...@list.nist.gov <pqc-...@list.nist.gov> On Behalf Of Markku-Juhani O. Saarinen

Sent: Tuesday, September 17, 2024 1:17 PM
To: pqc-forum <pqc-...@list.nist.gov>
Cc: pqc-...@list.nist.gov <pqc-...@list.nist.gov>; Paul Hoffman <paul.h...@icann.org>; Jeff Andersen <jeffan...@google.com>

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/8704027e-85ad-4f63-a2f2-f80ae7e824fen%40list.nist.gov.

[Mike Ounsworth]

Hmm, Markku, while interesting, I don’t think that answers Jeff’s question about whether:

ML-DSA-87.Sign( SHA2-384(M) )

 

or

 

HashML-DSA-87.Sign( SHA2-384(M), SHA2-512 )

 

would be considered to be Category 5 because of ML-DSA-87, or Category 4 because the message being signed has collision-resistance of SHA2-384, which is literally the definition of Category 4.

 

I think this is fundamentally a question about FIPS interpretation, not a question about CNSA 2.0 interpretation.

 

---

Mike Ounsworth

 

From: 'Brent Kimberley' via pqc-forum <pqc-...@list.nist.gov>

Sent: Tuesday, September 17, 2024 12:28 PM
To: Markku-Juhani O. Saarinen <mjos....@gmail.com>; pqc-forum <pqc-...@list.nist.gov>
Cc: pqc-...@list.nist.gov <pqc-...@list.nist.gov>; Paul Hoffman <paul.h...@icann.org>; Jeff Andersen <jeffan...@google.com>

Subject: [EXTERNAL] RE: [Ext] [pqc-forum] ML-DSA-87, SHA-384, and CNSA 2.0

 

Noted. Thanks. From: pqc-forum@ list. nist. gov <pqc-forum@ list. nist. gov> On Behalf Of Markku-Juhani O. Saarinen Sent: September 17, 2024 1: 17 PM To: pqc-forum <pqc-forum@ list. nist. gov> Cc: pqc-. . . @ list. nist. gov <pqc-forum@ list. nist. gov>;

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/YT3PR01MB1054437BE307B8AED2530CCC5FA612%40YT3PR01MB10544.CANPRD01.PROD.OUTLOOK.COM.

[Ivan Mclean]

For what it's worth, w.r.t. collision resistance, CNSA 2.0 also appears to consider SHA-256/192, SHAKE256/192 as entirely acceptable and compliant primitives for image signing when used together with LMS/XMSS

Ivan

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CH0PR11MB5739E7FE37005F991A21E29F9F612%40CH0PR11MB5739.namprd11.prod.outlook.com.

[Scott Fluhrer (sfluhrer)]

Actually, with LMS and XMSS, collision resistance is not an issue; they depend on (second) preimage resistance (or something close to that)

 

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CABNwLct-DJAsua0QW-SgJeRhnz4XfZiXARg4vhHU2KEt9r7f%3DA%40mail.gmail.com.

[Andrey Jivsov]

I would like an official answer too, but here is my understanding.

CNSA 2.0, as its predecessor Suite B, targets overall SHA-384 collision resistance security strength (or AES-192-level). Some algorithms, for various reasons, are upgraded from that goal (e.g. to AES-256, ML-DSA, XMSS SHA-256 width, etc). 

For this reason ML-DSA-87.sign( SHA384(M) ) should be compatible with CNSA 2.0, while e.g. ML-DSA-87.sign( SHA256(M) ) is not.

In practice, one won't pass just SHA384(M) to signing, but that and perhaps some metadata, which will be a message for the ML-DSA-87.sign() step.

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CH0PR11MB544490DEC85CC4853B00872CC1612%40CH0PR11MB5444.namprd11.prod.outlook.com.

[Blumenthal, Uri - 0553 - MITLL]

While I can’t speak for the NSA, my work requires paying attention to CNSA.

 

The way we read CNSA-2.0, it says:

 

1. ML-DSA-87 is approved for signing <whatever> that requires digital signature, no restrictions given.
2. SHA384 is approved for hashing <whatever>, no limitation specified.

 

Therefore, if I decide to sign (with ML-DSA-87) a hash (created by SHA384), I’m perfectly fine and in compliance with CNSA-2.0.

 

QED   (or ask NSA – but I’m willing to bet their answer would be along the same lines)

--

V/R,

Uri

 

There are two ways to design a system. One is to make it so simple there are obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.

                                                                                                                                        C. A. R. Hoare

 

I was a shepherd to fools

Causelessly bold or afraid.

They would not abide by my rules.

Yet they escaped. For I stayed.

                                    R. Kipling “Epitaphs of the War. Convoy Escort”

 

 

From: 'Scott Fluhrer (sfluhrer)' via pqc-forum <pqc-...@list.nist.gov>
Date: Tuesday, September 17, 2024 at 15:20
To: Ivan Mclean <imc...@google.com>, Mike Ounsworth <Mike.Ou...@entrust.com>
Cc: Brent Kimberley <Brent.K...@durham.ca>, Markku-Juhani O. Saarinen <mjos....@gmail.com>, pqc-forum <pqc-...@list.nist.gov>, Paul Hoffman <paul.h...@icann.org>, Jeff Andersen <jeffan...@google.com>
Subject: RE: [Ext] [pqc-forum] ML-DSA-87, SHA-384, and CNSA 2.0

Actually, with LMS and XMSS, collision resistance is not an issue; they depend on (second) preimage resistance (or something close to that) From: 'Ivan Mclean' via pqc-forum <pqc-forum@ list. nist. gov> Sent: Tuesday, September 17, 2024 3: 10

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside the Laboratory.

 

ZjQcmQRYFpfptBannerEnd

.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CH0PR11MB544490DEC85CC4853B00872CC1612%40CH0PR11MB5444.namprd11.prod.outlook.com.

[Andrey Jivsov]

[Jeff Andersen]

I think those takes are sensible. To add on:

I went back to basics to review the definition of security strength categories. From the PQC security evaluation criteria section 4.A.5 (hat-tip to the recent thread for making this easy to find), security categories are defined in terms of "relevant security definitions". For example, category 5 means: "Any attack that breaks the relevant security definition must require computational resources comparable to or greater than those required for key search on a block cipher with a 256-bit key (e.g. AES 256)".

Section 4.A.4 states that the relevant security definition for digital signatures is the EUF-CMA property. EUF-CMA is an adversarial game defined in terms of a digital signature scheme and a set of attacker-chosen messages.

So. In the case of ML-DSA, the pre-hash is computed on messages that will be signed; in other words, it's part of the signature scheme that would be evaluated in the EUF-CMA game. Therefore, the strength of the pre-hash matters to whether the signature scheme can claim category 5 strength.

Digital signature primitives like ML-DSA-87 can be used to sign messages of any kind, without affecting the scheme's security category. In other words, ML-DSA's security category does not apply to the cryptographic system as a whole, merely the signature primitive itself.

Looking closely at the language of CNSA 2.0: it mandates the use of category 5 parameters for ML-DSA, but does not mandate that the security of the cryptographic system as a whole meets category 5 standards. Indeed, there is no relevant definition by which we could say whether a multi-faceted cryptographic system meets any given security category, because security categories are applied to cryptographic primitives and are defined in terms of whether that primitive meets IND-CCA2 / IND-CPA / EUF-CMA.

Opinion: for composite schemes like those being drafted at IETF, any pre-hashes would be part of the signature scheme for that composite construction. A hypothetical pairing of SHA-384 with ML-DSA-87 would not affect the security category of the ML-DSA-87 portion, but if the EUF-CMA game is being played in terms of the composite signature scheme, that scheme would earn an overall security category of 4. Under that interpretation, it seems like CNSA 2.0 may be under-specified; the ML-DSA parameters are not the only inputs to the security strength of a signature scheme. In this case I don't think it matters very much, because CNSA 2.0's allowance of SHA-384 signals NSA's support for primitives with category 4 strength. So, a hypothetical composite signature scheme with a SHA-384 pre-hash step which is performed prior to invoking ML-DSA-87 seems like it should be okay with NSA. I guess the question to ask NSA is, if NIST had defined an ML-DSA parameter set with category 4 security, would NSA have approved it for CNSA 2.0.

In any case, I can't see any reason why ML-DSA-87.sign(k, SHA512(M)) where M is a SHA-384 digest (or derived from SHA-384 digests) wouldn't be acceptable to NSA.

--Jeff Andersen

[Blumenthal, Uri - 0553 - MITLL]

Note that security levels is the NIST thing: CNSA does not use that language, and simply tells you what you may (or may not) employ. Both ML-DSA-87 and SHA384 belong to the “allowed”… What more does one need to know?

As for Composite - NSA explicitly stated that they will not require them. People even thought that NSA would forbid Composites on the government systems - and somebody from the Agency issued clarification: not forbidden, but not desired/required. So, my guess is: don’t look at CNSA 2.0 for guidance on Composite - it won’t be coming there. 

—

Regards,

Uri

Secure Resilient Systems and Technologies

MIT Lincoln Laboratory

On Sep 17, 2024, at 20:06, 'Jeff Andersen' via pqc-forum <pqc-...@list.nist.gov> wrote:



I think those takes are sensible. To add on: I went back to basics to review the definition of security strength categories. From the PQC security evaluation criteria section 4. A. 5 (hat-tip to the recent thread for making this easy to find),

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside the Laboratory.

 

ZjQcmQRYFpfptBannerEnd

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CADRsRuW01v4z7byUEzVsRkwe8x%3D_2Fs4Ak9Jp34GaKYh-nuhBg%40mail.gmail.com.

[Jeff Andersen]

Hi Uri,

CNSA 2.0 doesn't appear to allow ML-DSA-87 by name; rather it includes the directive that for CRYSTALS-Dilithium, modules "use Level V parameters for all classification levels." This seems to signal that NSA does care about security categories. Hence the original question about what happens to the security category under certain pre-hash scenarios.

--Jeff Andersen

[Blumenthal, Uri - 0553 - MITLL]

Page 3 of https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF clearly states:

 

ML-DSA (aka CRYSTALS-Dilithium). Use Category 5 parameters, ML-DSA-87, for all classification levels.

 

Also, for Secure Hash:

 

Use SHA-384 or SHA512 for all classification levels.

 

Enough said?

--

V/R,

Uri

 

There are two ways to design a system. One is to make it so simple there are obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.

                                                                                                                                     -  C. A. R. Hoare

 

 

From: Jeff Andersen <jeffan...@google.com>
Date: Tuesday, September 17, 2024 at 20:47
To: Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu>
Cc: pqc-forum <pqc-...@list.nist.gov>, Scott Fluhrer (sfluhrer) <sflu...@cisco.com>, Ivan Mclean <imc...@google.com>, Mike Ounsworth <Mike.Ou...@entrust.com>, Brent Kimberley <Brent.K...@durham.ca>, Markku-Juhani O. Saarinen <mjos....@gmail.com>, Paul Hoffman <paul.h...@icann.org>, Andrey Jivsov <and...@brainhub.org>
Subject: Re: [Ext] [pqc-forum] ML-DSA-87, SHA-384, and CNSA 2.0

Hi Uri, CNSA 2. 0 doesn't appear to allow ML-DSA-87 by name; rather it includes the directive that for CRYSTALS-Dilithium, modules "use Level V parameters for all classification levels. " This seems to signal that NSA does care about

[Jeff Andersen]

Ah that is my bad, I was looking at the original CNSA 2.0, not the FAQ.

--Jeff Andersen

[Blumenthal, Uri - 0553 - MITLL]

In case I misunderstood your specific question: in that CNSA FAQ quote, Category level was (obviously) applicable only to NIST PQC algorithms (e.g., ML-DSA) that had variants with different levels (ML-DSA-44, ML-DSA-65, ML-DSA-87) – so NSA told you which one they require out of three possible options.

 

SHA384 does not belong there (has no options/levels available), and is explicitly approved everywhere (see the quote).

[Mike Ounsworth]

Hi Jeff, Uri,

 

This is a good point. While NSA has been clear that they don’t require / desire hybrids, it would be unfortunate if we designed composites in a way that made them forbidden.

 

Jeff, I think you’re looking at the old pre-adoption version of the draft. The current active version is draft-ietf-lamps-pq-composite-sigs-02, but for this point it doesn’t matter because we have not changed the pre-hash pairings since well before draft-ounsworth-pq-composite-sigs-13. We are using SHA2-256 as the pre-hash for ML-DSA44, and SHA2-512 as the pre-hash for ML-DSA-65 and -87. So I think we’re good.

 

I’m glad that your hypothetical about a SHA2-384 + ML-DSA-87 is only hypothetical, and no change is required to the draft😝

---

Mike Ounsworth

 

From: Jeff Andersen <jeffan...@google.com>
Sent: Tuesday, September 17, 2024 7:47 PM
To: Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu>
Cc: pqc-forum <pqc-...@list.nist.gov>; Scott Fluhrer (sfluhrer) <sflu...@cisco.com>; Ivan Mclean <imc...@google.com>; Mike Ounsworth <Mike.Ou...@entrust.com>; Brent Kimberley <Brent.K...@durham.ca>; Markku-Juhani O. Saarinen <mjos....@gmail.com>; Paul Hoffman <paul.h...@icann.org>; Andrey Jivsov <and...@brainhub.org>
Subject: [EXTERNAL] Re: [Ext] [pqc-forum] ML-DSA-87, SHA-384, and CNSA 2.0

 

Hi Uri, CNSA 2. 0 doesn't appear to allow ML-DSA-87 by name; rather it includes the directive that for CRYSTALS-Dilithium, modules "use Level V parameters for all classification levels. " This seems to signal that NSA does care about

Hi Uri,

 

CNSA 2.0 doesn't appear to allow ML-DSA-87 by name; rather it includes the directive that for CRYSTALS-Dilithium, modules "use Level V parameters for all classification levels." This seems to signal that NSA does care about security categories. Hence the original question about what happens to the security category under certain pre-hash scenarios.

--Jeff Andersen

 

 

On Tue, Sep 17, 2024 at 5:36 PM Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu> wrote:

Note that security levels is the NIST thing: CNSA does not use that language, and simply tells you what you may (or may not) employ. Both ML-DSA-87 and SHA384 belong to the “allowed”… What more does one need to know?

 

As for Composite - NSA explicitly stated that they will not require them. People even thought that NSA would forbid Composites on the government systems - and somebody from the Agency issued clarification: not forbidden, but not desired/required. So, my guess is: don’t look at CNSA 2.0 for guidance on Composite - it won’t be coming there. 

—

Regards,

Uri

 

Secure Resilient Systems and Technologies

MIT Lincoln Laboratory

On Sep 17, 2024, at 20:06, 'Jeff Andersen' via pqc-forum <pqc-...@list.nist.gov> wrote:



I think those takes are sensible. To add on: I went back to basics to review the definition of security strength categories. From the PQC security evaluation criteria section 4. A. 5 (hat-tip to the recent thread for making this easy to find),

I think those takes are sensible. To add on:

[Phillip Hallam-Baker]

As we learned from @Pv6, there are two very different problems.

1) Defining a satisfactory end point

2) Arriving at that endpoint.

The devil is in the deployment. The second is vastly more difficult than the first.

The point surely was that it has to be possible to deploy ML-KEM and ML-DSA without backup from an established algorithm and achieve acceptable security. But the problem is that it is going to take a long time to achieve a transition, it took over a decade to get SHA2 to replace SHA1 and that was almost a 1:1 replacement.

In the short term, we are going to see a lot of systems at the transport level that use RSA/ECC certificates to establish a channel and then use a PQC ephemeral. We will do that because no CA can start issuing certificates until we have FIPS-140 HSMs but we want traffic to be secure against later quantum cryptanalysis.

We are also going to see the reverse, PQC key exchanges which then hand off to applications which then do their own ephemerals for forward secrecy and not necessarily PQC.

We have to learn how to build such systems securely.

We are also going to need hybrids in IoT because while the IoT world has finally started moving to platforms like Raspberry Pi Nano and ESP32 that have strong 32bit CPUs and 256 KB of memory, that 256KB has to do a lot more than ML-KEM and ML-DSA and demanding 64KB just for PQC is going to be a very big ask.

Doing ECC on chip in a separate CPU is no problem. You can use Threshold to bind an infinite number (OK, 2^448) keys to an embedded key never leaves the device. But ML-KEM and ML-DSA are going to require quite a few gates with no real way to avoid that.

Finally, of course I have to mention that there is no threshold mode for ML-KEM or ML-DSA. Well not a secure one. Threshold is how we do separation of duties and separation of duties is essential for securing data at rest.

If my file server is breached, well I don’t care because my solution to data at rest is not keeping any sensitive stuff. But if I was running XYZ healthcare and there was a file server breach, I would be much less worried about a breach of data encrypted through a mechanism possibly vulnerable to CRQC decryption in several years time than a breach of plaintext.

We really have to get away from the notion that ‘NIST says X’ or ‘Google says Y’ as carved in stone assertions. Not least because treating their statements as such is going to strongly discourage open discussion which is what we need at this stage. We have a community of expertise and we generally move as a herd. It is important to take NIST’s opinions seriously if we plan to sell stuff to the US Federal Govt. But comments on slide decks from five years ago are not the way NIST makes such opinions known.

To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+unsubscribe@list.nist.gov.

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/8704027e-85ad-4f63-a2f2-f80ae7e824fen%40list.nist.gov.

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.

--
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+unsubscribe@list.nist.gov.

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/YT3PR01MB1054437BE307B8AED2530CCC5FA612%40YT3PR01MB10544.CANPRD01.PROD.OUTLOOK.COM.

--
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+unsubscribe@list.nist.gov.

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CH0PR11MB5739E7FE37005F991A21E29F9F612%40CH0PR11MB5739.namprd11.prod.outlook.com.

--
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+unsubscribe@list.nist.gov.

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CABNwLct-DJAsua0QW-SgJeRhnz4XfZiXARg4vhHU2KEt9r7f%3DA%40mail.gmail.com.

--
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+unsubscribe@list.nist.gov.

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CH0PR11MB544490DEC85CC4853B00872CC1612%40CH0PR11MB5444.namprd11.prod.outlook.com.

--
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+unsubscribe@list.nist.gov.

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CADRsRuW01v4z7byUEzVsRkwe8x%3D_2Fs4Ak9Jp34GaKYh-nuhBg%40mail.gmail.com.

--

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+unsubscribe@list.nist.gov.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CH0PR11MB5739332DDB4B9C7027F169649F622%40CH0PR11MB5739.namprd11.prod.outlook.com.

[Stern, Morgan B]

Thanks for starting the discussion. To answer Jeff's original question, his module is not required to move away from SHA384 to comply with CNSA 2.0. SHA384 is allowed in CNSA 2.0 for any usage that asks for a hash, so if the message M someone is signing with ML-DSA-87 happens to be a SHA384 hash, that is fine. Similarly, if it happens to be a SHA512 hash, that is fine.  If the message is (say) a SHA256 hash and that is part of the cryptographic protocol, then that is not fine as SHA256 is not allowed in CNSA 2.0.

I should further say, we are not at this point anticipating the usage of the algorithm “HashML-DSA-87” (as defined in section 5.4 of FIPS 204). In those usecases that require a pre-hash our assumption is that the usecase determines the pre-hash and then the algorithm "ML-DSA-87" will be used.

I'm happy to answer further specific questions from NSS users and vendors; please send them to NSACryp...@nsa.gov

Morgan Stern
NSA Cybersecurity

 

 

From: 'Jeff Andersen' via pqc-forum <pqc-...@list.nist.gov>
Sent: Tuesday, September 17, 2024 12:00 PM
To: pqc-...@list.nist.gov
Subject: [Non-DoD Source] [pqc-forum] ML-DSA-87, SHA-384, and CNSA 2.0

 

Scenario: a module currently implements a service that hashes data using SHA-384, and signs the digest M with ECDSA. SHA-384 as a hash algorithm is acceptable for CNSA 2.0, while ECDSA as a signature algorithm is not.

 

The module wishes to adopt ML-DSA for signing to be compliant with CNSA 2.0. For ML-DSA, CNSA 2.0 mandates "Level V parameters for all classification levels". FIPS 204 denotes ML-DSA-87 as "Category 5".

 

Question: while adopting ML-DSA-87 for signing M, is the module also required to move away from SHA-384 for generating M? Notwithstanding CNSA 2.0 allowing SHA-384 for hashing?

 

FIPS 204 section 5.4 describes a mechanism for pre-hashing the message before signing it with ML-DSA. That section states: "In order to maintain the same level of security strength when the content is hashed at the application level or using HashML-DSA, the digest that is signed needs to be generated using an approved hash function or XOF (e.g., from FIPS 180 or FIPS 202) that provides at least 𝜆 bits of classical security strength against both collision and second preimage attacks."

 

Cross-referencing FIPS 204 section 4 and FIPS 202 section A.1: if one uses ML-DSA-87, pre-hashes may not be generated with SHA-384, but could be generated with SHA-512.

 

There are a couple possible interpretations:

1. The pre-hash described in FIPS 204 section 5.4 is part of the signature algorithm and bears no relation to the data that is signed, which may be an arbitrary blob. Therefore, it is acceptable to generate M using SHA-384, then pre-hash it using SHA-512, then sign the pre-hash with ML-DSA-87.
   
   This would extend to leveraging IETF draft composite signatures with algorithm ID "id-MLDSA87-ECDSA-P384-SHA512", where M is a SHA-384 digest, M' is a SHA-512 digest, and S1 is an ML-DSA-87 signature.
2. If ML-DSA-87 is being used to sign a hash, the hash must have been computed with a stronger hash algorithm than SHA-384, such as SHA-512. Otherwise the security strength of ML-DSA-87 would no longer meet level 5 requirements and thus would no longer satisfy CNSA 2.0. As an implication: although CNSA 2.0 nominally allows SHA-384, it effectively does not allow that algorithm if the resulting digest will be signed by ML-DSA.
   
   Taken to its logical conclusion, this would also imply that it is not allowed to use ML-DSA-87 to sign a message M which is a concatenation of multiple digests, where any component digest is computed using SHA-384.

 

IMO, interpretation #1 is the most imminently sensible. However, I see enough room in the specs for a strict reading to potentially arrive at #2, even though the implications are rather weird.

 

Interested in others' thoughts.

 

--Jeff Andersen

--
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 on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CADRsRuXwWYgjgkwqeBL1Sioj8OVZ0nDubqy50FCUm51Cwz2MLg%40mail.gmail.com.

[John Mattsson]

Phillip Hallam-Baker wrote:

>We are also going to need hybrids in IoT because while the IoT world has finally started moving to

>platforms like Raspberry Pi Nano and ESP32 that have strong 32bit CPUs and 256 KB of memory, that >256KB has to do a lot more than ML-KEM and ML-DSA and demanding 64KB just for PQC is going to be a >very big ask.

 

You cannot describe the IoT world as a single thing. The IoT world is consisting of vastly different devices/nodes and networks. Bandwith, CPU, memory, storage, engery, and power differ with _many_ orders of magniture. Some devices/nodes are not constrained at all and could have run pqRSA. Others are extremely constrained and cannot run _any_ of the current PQC standards. The low end of IoT is not moving that much, when things get cheaper, some applications upgrade, but typically new applications are found for the now cheaper devices. In constrained IoT, the CPU is typically the least constraining factor. Often bandwith, memory, storage, energy, and power are more more limiting.

 

That said I agree that we in general need hybrids for both key exchange and long-term signatures. There are still an alarming number of very serious implementation problems in many RSA and ECC implementations. I expect the new PQC standards to be worse in the beginning. I like that you discuss PQC hybrids and threshold cryptography in the same mail. In the past I have seen situations where threshold cryptography (RSA + ECC) saves the day as one of the implementations had problems with the implementation.

 

Cheers,

John

 

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/8704027e-85ad-4f63-a2f2-f80ae7e824fen%40list.nist.gov.

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.

--
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 on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/YT3PR01MB1054437BE307B8AED2530CCC5FA612%40YT3PR01MB10544.CANPRD01.PROD.OUTLOOK.COM.

--
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 on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CH0PR11MB5739E7FE37005F991A21E29F9F612%40CH0PR11MB5739.namprd11.prod.outlook.com.

--
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 on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CABNwLct-DJAsua0QW-SgJeRhnz4XfZiXARg4vhHU2KEt9r7f%3DA%40mail.gmail.com.

--
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 on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CH0PR11MB544490DEC85CC4853B00872CC1612%40CH0PR11MB5444.namprd11.prod.outlook.com.

--
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 on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CADRsRuW01v4z7byUEzVsRkwe8x%3D_2Fs4Ak9Jp34GaKYh-nuhBg%40mail.gmail.com.

--
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 on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CH0PR11MB5739332DDB4B9C7027F169649F622%40CH0PR11MB5739.namprd11.prod.outlook.com.

--
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 on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAMm%2BLwgfX3csjP80LvesBm4wSbjzp9n5LjT4egnmz5YJbmEVXw%40mail.gmail.com.

[Markku-Juhani O. Saarinen]

On Wednesday, September 18, 2024 at 9:43:41 PM UTC Stern, Morgan B wrote:

Thanks for starting the discussion. To answer Jeff's original question, his module is not required to move away from SHA384 to comply with CNSA 2.0. SHA384 is allowed in CNSA 2.0 for any usage that asks for a hash, so if the message M someone is signing with ML-DSA-87 happens to be a SHA384 hash, that is fine. Similarly, if it happens to be a SHA512 hash, that is fine.  If the message is (say) a SHA256 hash and that is part of the cryptographic protocol, then that is not fine as SHA256 is not allowed in CNSA 2.0.

Stating the obvious: Using SHA384 of course makes the signature scheme Category 4 (SHA384 is the definition on Category 4). So we assume that interpretation is that the "Category 5" requirement applies only to internal hash operations and lattice parameter selection of ML-DSA-87, not to the actual security of the scheme.

I should further say, we are not at this point anticipating the usage of the algorithm “HashML-DSA-87” (as defined in section 5.4 of FIPS 204). In those usecases that require a pre-hash our assumption is that the usecase determines the pre-hash and then the algorithm "ML-DSA-87" will be used.

You should share an exact specification on how to do this. ML-DSA (as defined in Sections 5.2 and 5.3 of FIPS 204) does not support SHA-384 or SHA-512. Only HashML-DSA has support for SHA-2.  Certificate formats are expected to follow the NIST standards -- if you're suggesting to pass a raw hash as "M" for ML-DSA, this would require yet another set of OIDs. If it is the intention that COTS operating systems,  browsers, and software and hardware can be used for DoD PKI, it would seem more sensible not to diverge from the NIST standard like this.

I'm happy to answer further specific questions from NSS users and vendors; please send them to NSACryp...@nsa.gov

Posting this on the public forum as otherwise there would not be interoperable implementations.

Best Regards,

- markku

[Blumenthal, Uri - 0553 - MITLL]

Thanks for starting the discussion. To answer Jeff's original question, his module is not required to move away from SHA384 to comply with CNSA 2.0. SHA384 is allowed in CNSA 2.0 for any usage that asks for a hash, so if the message M someone is signing with ML-DSA-87 happens to be a SHA384 hash, that is fine. Similarly, if it happens to be a SHA512 hash, that is fine.  If the message is (say) a SHA256 hash and that is part of the cryptographic protocol, then that is not fine as SHA256 is not allowed in CNSA 2.0.

Stating the obvious: Using SHA384 of course makes the signature scheme Category 4 (SHA384 is the definition on Category 4). So we assume that interpretation is that the "Category 5" requirement applies only to internal hash operations and lattice parameter selection of ML-DSA-87, not to the actual security of the scheme.

 

Re-stating the obvious: only NIST cares for and speaks of Categories.

 

Thus, speculating about “what NIST Category would a combination of CNSA-allowed components be” might be entertaining, but is totally useless from all practical points of view.

I should further say, we are not at this point anticipating the usage of the algorithm “HashML-DSA-87” (as defined in section 5.4 of FIPS 204). In those usecases that require a pre-hash our assumption is that the usecase determines the pre-hash and then the algorithm "ML-DSA-87" will be used.

You should share an exact specification on how to do this. ML-DSA (as defined in Sections 5.2 and 5.3 of FIPS 204) does not support SHA-384 or SHA-512.

 

Apparently, CNSA does not want to deal with “pre-hash” concepts, and considers the two operations as totally independent. I.e., you want to submit your entire message to ML-DSA-87 – fine. You want to hash it before (because the entire message is too big, or for whatever other reason) – also fine. They don’t seem to want to distinguish between signing a message that is 0x0102030405 and signing a message SHA384 digest that is 0x0102030405. I don’t see what more one could specify here.

 

Don’t consider “pre-hash” as a part of signature algorithm: NIST may want to do that, NSA apparently doesn’t – as reflected in their CNSA-2.0 and its FAQ.

 

Only HashML-DSA has support for SHA-2.  Certificate formats are expected to follow the NIST standards -- if you're suggesting to pass a raw hash as "M" for ML-DSA, this would require yet another set of OIDs.

 

I can’t possibly see why. From CNSA point of view, your message M can be anything, including a hash of another message. There’s no concept of “raw” (or “cooked”) hash as input, as opposed to “non-raw” or “non-hash” input.

 

 

Let’s not complicate things more than we have to, shall we?

 

 

   

From: 'Jeff Andersen' via pqc-forum <pqc-...@list.nist.gov>
Sent: Tuesday, September 17, 2024 12:00 PM
To: pqc-...@list.nist.gov
Subject: [Non-DoD Source] [pqc-forum] ML-DSA-87, SHA-384, and CNSA 2.0

 

Scenario: a module currently implements a service that hashes data using SHA-384, and signs the digest M with ECDSA. SHA-384 as a hash algorithm is acceptable for CNSA 2.0, while ECDSA as a signature algorithm is not.

 

The module wishes to adopt ML-DSA for signing to be compliant with CNSA 2.0. For ML-DSA, CNSA 2.0 mandates "Level V parameters for all classification levels". FIPS 204 denotes ML-DSA-87 as "Category 5".

 

Question: while adopting ML-DSA-87 for signing M, is the module also required to move away from SHA-384 for generating M? Notwithstanding CNSA 2.0 allowing SHA-384 for hashing?

 

FIPS 204 section 5.4 describes a mechanism for pre-hashing the message before signing it with ML-DSA. That section states: "In order to maintain the same level of security strength when the content is hashed at the application level or using HashML-DSA, the digest that is signed needs to be generated using an approved hash function or XOF (e.g., from FIPS 180 or FIPS 202) that provides at least 𝜆 bits of classical security strength against both collision and second preimage attacks."

 

Cross-referencing FIPS 204 section 4 and FIPS 202 section A.1: if one uses ML-DSA-87, pre-hashes may not be generated with SHA-384, but could be generated with SHA-512.

 

There are a couple possible interpretations:

1.       The pre-hash described in FIPS 204 section 5.4 is part of the signature algorithm and bears no relation to the data that is signed, which may be an arbitrary blob. Therefore, it is acceptable to generate M using SHA-384, then pre-hash it using SHA-512, then sign the pre-hash with ML-DSA-87.

This would extend to leveraging IETF draft 

composite signatures with algorithm ID "id-MLDSA87-ECDSA-P384-SHA512", where M is a SHA-384 digest, M' is a SHA-512 digest, and S1 is an ML-DSA-87 signature.

2.       If ML-DSA-87 is being used to sign a hash, the hash must have been computed with a stronger hash algorithm than SHA-384, such as SHA-512. Otherwise the security strength of ML-DSA-87 would no longer meet level 5 requirements and thus would no longer satisfy CNSA 2.0. As an implication: although CNSA 2.0 nominally allows SHA-384, it effectively does not allow that algorithm if the resulting digest will be signed by ML-DSA.

Taken to its logical conclusion, this would also imply that it is not allowed to use ML-DSA-87 to sign a message M which is a concatenation of multiple digests, where any component digest is computed using SHA-384.

IMO, interpretation #1 is the most imminently sensible. However, I see enough room in the specs for a strict reading to potentially arrive at #2, even though the implications are rather weird.

 

Interested in others' thoughts.

 

--Jeff Andersen

--
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 on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CADRsRuXwWYgjgkwqeBL1Sioj8OVZ0nDubqy50FCUm51Cwz2MLg%40mail.gmail.com.

--
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 on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/924b1c22-fdde-4fef-9954-e47afc4e0a29n%40list.nist.gov.

[Markku-Juhani O. Saarinen]

On Thursday, September 19, 2024 at 3:23:46 PM UTC Blumenthal, Uri - 0553 - MITLL wrote:

Thanks for starting the discussion. To answer Jeff's original question, his module is not required to move away from SHA384 to comply with CNSA 2.0. SHA384 is allowed in CNSA 2.0 for any usage that asks for a hash, so if the message M someone is signing with ML-DSA-87 happens to be a SHA384 hash, that is fine. Similarly, if it happens to be a SHA512 hash, that is fine.  If the message is (say) a SHA256 hash and that is part of the cryptographic protocol, then that is not fine as SHA256 is not allowed in CNSA 2.0.

Stating the obvious: Using SHA384 of course makes the signature scheme Category 4 (SHA384 is the definition on Category 4). So we assume that interpretation is that the "Category 5" requirement applies only to internal hash operations and lattice parameter selection of ML-DSA-87, not to the actual security of the scheme.

Re-stating the obvious: only NIST cares for and speaks of Categories.

Hi Uri,

Well, the CNSA FAQ States that: "Use Category 5 parameter, ML-DSA-87, for all classification levels," hence the question. If they didn't explicitly mention that they want Category 5, we wouldn't be asking. https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/1/CSI_CNSA_2.0_FAQ_.PDF

 

Only HashML-DSA has support for SHA-2.  Certificate formats are expected to follow the NIST standards -- if you're suggesting to pass a raw hash as "M" for ML-DSA, this would require yet another set of OIDs.

I can’t possibly see why. From CNSA point of view, your message M can be anything, including a hash of another message. There’s no concept of “raw” (or “cooked”) hash as input, as opposed to “non-raw” or “non-hash” input.

Recall one of the biggest use cases for signature algorithms is in PKI, CAC cards etc, and the way those work is via certificates that identify the signature scheme with an OID. DoD is full of Windows computers, the PKI stuff they is use is largely off-the-shelf. Vendors need to know how they expect these things to work -- like the IETF specs or some other way. The suggested behavior (of not using the HashML-DSA padding) would make certificates non-interoperable otherwie.

When the browser in a DoD Windows box sees a "ML-DSA-87" OID in a certificate, how is it going to know if it is to be interpret the signature in "CNSA" way or the one that is defined by IETF / NIST if those are the same OID? 

Cheers,

-markku

[Blumenthal, Uri - 0553 - MITLL]

Well, the CNSA FAQ States that: "Use Category 5 parameter, ML-DSA-87, for all classification levels," hence the question. If they didn't explicitly mention that they want Category 5, we wouldn't be asking. https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/1/CSI_CNSA_2.0_FAQ_.PDF

 

As I said,   Cat 5 only applies to the parameter set for ML-DSA-87 (and, of course, ML-KEM-1024 – but we aren’t talking about that now). There are no parameter sets for SHA2, thus specifying SHA384 (or SHA512) is sufficient.

Only HashML-DSA has support for SHA-2.  Certificate formats are expected to follow the NIST standards -- if you're suggesting to pass a raw hash as "M" for ML-DSA, this would require yet another set of OIDs.

I can’t possibly see why. From CNSA point of view, your message M can be anything, including a hash of another message. There’s no concept of “raw” (or “cooked”) hash as input, as opposed to “non-raw” or “non-hash” input.

 

Recall one of the biggest use cases for signature algorithms is in PKI, CAC cards etc, and the way those work is via certificates that identify the signature scheme with an OID. DoD is full of Windows computers, the PKI stuff they is use is largely off-the-shelf. Vendors need to know how they expect these things to work -- like the IETF specs or some other way. The suggested behavior (of not using the HashML-DSA padding) would make certificates non-interoperable otherwise.

 

Signature scheme in this context is ML-DSA-87. Irrespective of how its input was produced.

 

When the browser in a DoD Windows box sees a "ML-DSA-87" OID in a certificate, how is it going to know if it is to be interpret the signature in "CNSA" way or the one that is defined by IETF / NIST if those are the same OID? 

 

Assuming that “Hash-ML-DSA” would have its own OIDs, I see no problem: ML-DSA-87 (with “pre-hash” treated as an independent operation and out-of-scope) should be the same, whether under CNSA or IETF (or NIST).

 

 

[Markku-Juhani O. Saarinen]

On Thu, Sep 19, 2024 at 4:03 PM Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu> wrote:

Signature scheme in this context is ML-DSA-87. Irrespective of how its input was produced.

It's not quite that simple in the current specification (in "ipd" it was.)  There is a padding wrapper there now, and ML-DSA now has a domain separator indicating if prehashing was used or not. So the behavior is in fact different.

When the browser in a DoD Windows box sees a "ML-DSA-87" OID in a certificate, how is it going to know if it is to be interpret the signature in "CNSA" way or the one that is defined by IETF / NIST if those are the same OID? 

 

Assuming that “Hash-ML-DSA” would have its own OIDs, I see no problem: ML-DSA-87 (with “pre-hash” treated as an independent operation and out-of-scope) should be the same, whether under CNSA or IETF (or NIST).

Hash ML-DSA has OIDs have been published by NIST and are being integrated into X.509 certificate formats by IETF. "id-hash-ml-dsa-87-with-sha512" defines the functionality of HashML-DSA.Sign (Algorithm 4) and HashML-DSA.Verify (Algorithm 5) in FIPS 204. There is no OID for currently for doing the same with SHA384 -- that wouldn't be FIPS compliant anyway (due to the security issue that you say CNSA doesn't care about.) 

Anyway, just look at the details and you will see that what you say is not correct --  Interoperable signatures would not be produced as different bytes are getting signed in the NSA proposal and the actual HashML-DSA.Sign.

https://csrc.nist.gov/projects/computer-security-objects-register/algorithm-registration

id-hash-ml-dsa-87-with-sha512 OBJECT IDENTIFIER ::= { sigAlgs 34 }

These OIDs define *both* signature scheme and the hash function used, and hence one can't arbitrarily combine them (for certificates). The "pure-hash" OIDs of course use SHAKE256.

Best Regards,

-markku

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

[Sophie Schmieg]

I don't think you would necessarily need an OID here. If I understand Morgan's comment correctly, he would like this scenario to essentially be a protocol defining "For firmware signatures for AmazeHSM (tm), the firmware image is first hashed with SHA2-384 and this hash is then signed with ML-DSA87". Such a protocol can be a public standard, but equally could be just something that only AmazeHSM does, specified through their hardware and software of the HSM (Although I would encourage this hypothetical company to at least write a white paper about AmazeHSM's secure boot), but as long as the AmazeHSM public key is only ever used in this protocol, it would not need to specify the hash used in the message to be signed. Even in the case of a standardized protocol, which allows for multiple hash functions, the hash function could (and in my opinion should) be specified along with the key in the configuration for the software, and not be part of the message. While you can use an OID in such a configuration file, the string "SHA2-384" might be slightly easier to read.

Note that any deployment of a signature scheme always requires such a protocol to begin with, since you need to define what the "firmware image" in question is, how it is represented on the wire, etc. I really do not understand the wish for OIDs and HashML-DSA, it seems to me to not have a use case that would not be better served just using ML-DSA proper, describing the hash function to use to compress the input in the same place where the input itself is described.

--

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 on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CA%2BiU_q%3D-1PeQTLdmeJ2fq3dd8v0qX6tfc0CYwPVKDRMLiaCYEg%40mail.gmail.com.

--

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

[Blumenthal, Uri - 0553 - MITLL]

Assuming that “Hash-ML-DSA” would have its own OIDs, I see no problem: ML-DSA-87 (with “pre-hash” treated as an independent operation and out-of-scope) should be the same, whether under CNSA or IETF (or NIST).

Hash ML-DSA has OIDs have been published by NIST and are being integrated into X.509 certificate formats by IETF. "id-hash-ml-dsa-87-with-sha512" defines the functionality of HashML-DSA.Sign (Algorithm 4) and HashML-DSA.Verify (Algorithm 5) in FIPS 204. There is no OID for currently for doing the same with SHA384 -- that wouldn't be FIPS compliant anyway (due to the security issue that you say CNSA doesn't care about.) 

 

I could be wrong here – but you’re talking about HashML-DSA, which CNSA explicitly does not want to support. So, those OIDs would presumably be rejected by CNSA-compliant implementations.

 

Anyway, just look at the details and you will see that what you say is not correct --  Interoperable signatures would not be produced as different bytes are getting signed in the NSA proposal and the actual HashML-DSA.Sign.

 

I don’t think it’s possible (or even desirable?). HashML-DSA is not supported by CNSA, and cannot interoperate with CNSA-compliant products.

 

I’d expect interoperability between the outputs of “I hashed M with SHA384 (an independent process), and fed the results into ML-DSA-87 (an independent process) for signing” and “I took this 384-bit string, and fed it to ML-DSA-87 for signing”. But not with “I took M and ran it through HashML-DSA-87-with-SHA<whatever>”.

 

https://csrc.nist.gov/projects/computer-security-objects-register/algorithm-registration

id-hash-ml-dsa-87-with-sha512 OBJECT IDENTIFIER ::= { sigAlgs 34 }

 

Thanks for pointing out the NIST OID table.  IMHO, the OID you would use here is

 

            id-ml-dsa-87 OBJECT IDENTIFIER ::= { sigAlgs 19 }

 

and, of course,

 

            id-sha384 OBJECT IDENTIFIER ::= { hashAlgs 2 }

 

for hashing.

 

Because while you’re doing what technically is similar to HashML-DSA, this concept does not exist within the CNSA realm, and the domain separation required by NIST will prevent interoperability.

 

 

[Markku-Juhani O. Saarinen]

On Thu, Sep 19, 2024 at 6:06 PM Sophie Schmieg <ssch...@google.com> wrote:

I don't think you would necessarily need an OID here. If I understand Morgan's comment correctly, he would like this scenario to essentially be a protocol defining "For firmware signatures for AmazeHSM (tm), the firmware image is first hashed with SHA2-384 and this hash is then signed with ML-DSA87". Such a protocol can be a public standard, but equally could be just something that only AmazeHSM does, specified through their hardware and software of the HSM (Although I would encourage this hypothetical company to at least write a white paper about AmazeHSM's secure boot), but as long as the AmazeHSM public key is only ever used in this protocol, it would not need to specify the hash used in the message to be signed. Even in the case of a standardized protocol, which allows for multiple hash functions, the hash function could (and in my opinion should) be specified along with the key in the configuration for the software, and not be part of the message. While you can use an OID in such a configuration file, the string "SHA2-384" might be slightly easier to read.

Note that any deployment of a signature scheme always requires such a protocol to begin with, since you need to define what the "firmware image" in question is, how it is represented on the wire, etc. I really do not understand the wish for OIDs and HashML-DSA, it seems to me to not have a use case that would not be better served just using ML-DSA proper, describing the hash function to use to compress the input in the same place where the input itself is described.

Hi Sophie,

In proprietary, closed systems (like your firmware update from a vendor to a device) things are easy, but I'm not sure how to build certificates without OIDs. Signatures are used for authentication via X.509 certificates in many protocols that we'd still like to use. And as far as I understand, a (microsoft) operating system update comes with a certificate chain that is parsed by the OS. One needs to be able to uniquely parse from the update what kind of hash-signature-parameter-set-padding combo is used in each signature.

The way OIDs are defined by NIST, the same single number defines everything: the algorithm, parameter set, hash function, its length. Good or bad, this is the way the OIDs already are.

Cheers,

[Watson Ladd]

On Thu, Sep 19, 2024, 11:55 AM Markku-Juhani O. Saarinen <mjos....@gmail.com> wrote:

On Thu, Sep 19, 2024 at 6:06 PM Sophie Schmieg <ssch...@google.com> wrote:

I don't think you would necessarily need an OID here. If I understand Morgan's comment correctly, he would like this scenario to essentially be a protocol defining "For firmware signatures for AmazeHSM (tm), the firmware image is first hashed with SHA2-384 and this hash is then signed with ML-DSA87". Such a protocol can be a public standard, but equally could be just something that only AmazeHSM does, specified through their hardware and software of the HSM (Although I would encourage this hypothetical company to at least write a white paper about AmazeHSM's secure boot), but as long as the AmazeHSM public key is only ever used in this protocol, it would not need to specify the hash used in the message to be signed. Even in the case of a standardized protocol, which allows for multiple hash functions, the hash function could (and in my opinion should) be specified along with the key in the configuration for the software, and not be part of the message. While you can use an OID in such a configuration file, the string "SHA2-384" might be slightly easier to read.

Note that any deployment of a signature scheme always requires such a protocol to begin with, since you need to define what the "firmware image" in question is, how it is represented on the wire, etc. I really do not understand the wish for OIDs and HashML-DSA, it seems to me to not have a use case that would not be better served just using ML-DSA proper, describing the hash function to use to compress the input in the same place where the input itself is described.

Hi Sophie,

In proprietary, closed systems (like your firmware update from a vendor to a device) things are easy, but I'm not sure how to build certificates without OIDs. Signatures are used for authentication via X.509 certificates in many protocols that we'd still like to use. And as far as I understand, a (microsoft) operating system update comes with a certificate chain that is parsed by the OS. One needs to be able to uniquely parse from the update what kind of hash-signature-parameter-set-padding combo is used in each signature.

Surely you mean the key?

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CA%2BiU_qmiOZKpNE_cJNErZ2Sw5K%3D3s2Z-RRPL_FAJccemudTuzA%40mail.gmail.com.

[Markku-Juhani O. Saarinen]

On Thu, Sep 19, 2024 at 7:19 PM Watson Ladd <watso...@gmail.com> wrote:

On Thu, Sep 19, 2024, 11:55 AM Markku-Juhani O. Saarinen <mjos....@gmail.com> wrote:

On Thu, Sep 19, 2024 at 6:06 PM Sophie Schmieg <ssch...@google.com> wrote:

I don't think you would necessarily need an OID here. If I understand Morgan's comment correctly, he would like this scenario to essentially be a protocol defining "For firmware signatures for AmazeHSM (tm), the firmware image is first hashed with SHA2-384 and this hash is then signed with ML-DSA87". Such a protocol can be a public standard, but equally could be just something that only AmazeHSM does, specified through their hardware and software of the HSM (Although I would encourage this hypothetical company to at least write a white paper about AmazeHSM's secure boot), but as long as the AmazeHSM public key is only ever used in this protocol, it would not need to specify the hash used in the message to be signed. Even in the case of a standardized protocol, which allows for multiple hash functions, the hash function could (and in my opinion should) be specified along with the key in the configuration for the software, and not be part of the message. While you can use an OID in such a configuration file, the string "SHA2-384" might be slightly easier to read.

Note that any deployment of a signature scheme always requires such a protocol to begin with, since you need to define what the "firmware image" in question is, how it is represented on the wire, etc. I really do not understand the wish for OIDs and HashML-DSA, it seems to me to not have a use case that would not be better served just using ML-DSA proper, describing the hash function to use to compress the input in the same place where the input itself is described.

Hi Sophie,

In proprietary, closed systems (like your firmware update from a vendor to a device) things are easy, but I'm not sure how to build certificates without OIDs. Signatures are used for authentication via X.509 certificates in many protocols that we'd still like to use. And as far as I understand, a (microsoft) operating system update comes with a certificate chain that is parsed by the OS. One needs to be able to uniquely parse from the update what kind of hash-signature-parameter-set-padding combo is used in each signature.

Surely you mean the key?

Not really, albeit IMHO it is good practice that each key is used only with a single hash function and padding process. I was talking about the signature verification process in certificate chain parsing, where one of course needs to know what hash and padding to use.

[Sophie Schmieg]

I think this was a mistake we made with ECDSA, where we put the hash function for X509 certs into the signature instead of the key, ending up with not fully specified ECDSA keys. As far as I recall, RSA public keys do at least allow you to specify the hash function in X509 in the key correctly. I don't think we should repeat this mistake here, and instead fully specify the public key by including any necessary hash functions there. For ML-DSA that already happens by default, at least as long as you prehash using the algorithm 7 line 6 route, where the hash function is SHAKE256 of the message prefixed with SHAKE256 of the public key.

[Phillip Hallam-Baker]

It is a mess for pretty much every algorithm except ML-DSA where it is done right.

Binding the digest algorithm into the signature is essential to prevent a digest substitution attack. We did that for RSA in PKCS #1, in 1.5 but I am told we left it out in PSS.

For EdDSA and ECDSA we seem to have tried to tell people what digest to use which simply does not work because data is hashed for many purposes and the signer does not get to pick the digest. If I have hashed data with SHA-2-512 for my Merkle Tree, I am not rehashing with something else.

The upshot is that we have a lot of applications there that have security flaws because the signature formats don't support the application needs and because the need for binding was forgotten.

So the way to fix this as I see it is to propose a principled means of using the ML-DSAhashed manifest format with the other signature algorithms making use of the Context parameter to prevent semantic substitution at the message envelope layer. The envelope should probably take responsibility for domain separation at the application layer.

Using OIDs at this level is just what we do. I am a professional loather of ASN.1 but OIDs are the way we do the algorithms at the algorithmic level since PKCS#1.

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAEEbLAbp6dEG-iurzZgzzdTgkHkwsT9LcnR2eV89mtUp54zLZQ%40mail.gmail.com.