This is part of the issue with prehashing, there are a lot of different terminologies floating around to describe the same actions:
>From a cryptographic perspective, there is a single algorithm that takes a message and a private key as input and emits a signature valid for this message and the corresponding public key, with all hashing happening internally to the algorithm. The message in question can be any byte string, including potentially a hash computed in some other part of the protocol. In other words, we have some mathematical function Sign (FIPS 204 defines two of these ML-DSA and HashML-DSA), which, can be called on the output of another function Hash (as defined in e.g. FIPS 202 for SHA3), if you have a protocol that calls for the computation of Sign(Hash(m), sk). However, among closer inspection of ML-DSA and HashML-DSA, both of these algorithms can also be computed in a multi-party fashion. In other words, you can have two parties, who, together, compute the output of Sign, sharing some responsibilities of faithfully executing the internals of the algorithm. In this case, you have a digesting party D and a signing party S, with the digesting party computing external µ (or, in the case of HashML-DSA, H(m) as specified in FIPS 204), and the signing party using this partial computation to finish the computation of Sign. The end result is a protocol that calls for the computation of Sign(m, sk), computed by two parties (really straining my attempt at distinguishing protocols and algorithms). Importantly, there is no NIST document that would consider the output of D as a valid anything, as this hash is just an internal aspect of FIPS 204. In the end, there are, at my counting 4 different permissible ways of prehashing ML-DSA: - Have some higher level specification call for the hash of a message being computed before signing with ML-DSA (or HashML-DSA). I.e. the message input for ML-DSA is a hash. - Have one party compute ML-DSA's external µ, and the other party compute ML-DSA-finalize. - Have one party compute HashML-DSA's external µ, and the other party compute ML-DSA-finalize - Have one party compute H(m), and the other party compute HashML-DSA(H, H(m), sk) The line in the spec basically tells you that if you are not in the first case, you can use one of the two prehashing options FIPS 204 provides to land in one of the other three cases. My personal recommendation is to avoid the last two cases, but since the spec mentions them, they cause some confusion. On Mon, Jan 26, 2026 at 12:13 PM Nayna Jain <[email protected]> wrote: > > Hi, > > I am also trying to understand this part in the FIPS 204 about > PreHash, especially the last bold statement. > > *If the content to be signed is large, hashing of the content is often > performed at the application level. For example, in the Cryptographic > Message Syntax [29], a digest of the content may be computed, and that > digest is signed along with other attributes.** If the content is not > hashed at the application level, the pre-hash version of ML-DSA signing may > be used.* > > To me, the prehash version of ML-DSA implies that the application is going > to hash and then submit for signing. But here it says,* if the content > is not hashed at application level, use the prehash verison of ML-DSA,* > in that case what would be the input to the prehash version of ML-DSA? > > What am I missing? > > Thanks & Regards, > - Nayna > > On Thu, Aug 29, 2024 at 2:19 PM Michael Jones <[email protected]> > wrote: > >> Hi Orie, >> >> >> >> I would suggest defining algorithm identifiers for both the regular and >> pre-hash algorithms. That will make explicit what is happening, which I >> suspect will serve us well. Not doing this would cause an endless loop of >> repeating this same discussion over and over again. ;-) >> >> >> >> -- Mike >> >> >> >> *From:* [email protected] <[email protected]> *On Behalf Of *Orie >> Steele >> *Sent:* Tuesday, August 27, 2024 9:32 AM >> *To:* Phillip Hallam-Baker <[email protected]> >> *Cc:* Falko Strenzke <[email protected]>; pqc-forum < >> [email protected]>; cose <[email protected]> >> *Subject:* Re: [pqc-forum] Question regarding pure vs. pre-hash ML-DSA >> >> >> >> We're working on a COSE draft that tries to address a similar issue, but >> generically for traditional digital signature schemes as well: >> >> >> https://cose-wg.github.io/draft-ietf-cose-hash-envelope/draft-ietf-cose-hash-envelope.html#section-4-2.2.1 >> >> Just for the sake of separating out terminology, consider the following: >> >> - ECDSA with secp256r1 and SHA-256 HASH (we'll call this ESP256) >> - ESP256 used to produce a COSE Sign1 (we'll call this >> cose-sign1-with-esp256) >> - ESP256 used to produce a "hash envelope" (we'll call this >> cose-sign1-hash-envelope-with-esp256) >> >> Even in the case where "cose-sign1-with-esp256" and >> "cose-sign1-hash-envelope-with-esp256" sign the same payload, which could >> be the length of a SHA-256 hash, they can be distinguished by the presence >> of protected headers. >> >> It can be useful to consider a remote KMS interface, where the message >> needs to be conveyed to the signer in order for a signature to be produced. >> >> >> This is confusing to think about when you have "pre-hash" in both the raw >> crypto layer, and the protocol layer. >> >> I like to think about this problem from the perspective of what a client >> can do. >> >> Let the message / payload be a 1 TB LLM model. >> >> # Case 1 >> >> With HashML-DSA-65-SHA-256 and "normal cose-sign1" the client can do the >> following: >> >> Set the protected header to be { alg: HashML-DSA-65-SHA-256 } // crypto >> layer pre-hash >> Construct the Sig_structure as defined in >> https://datatracker.ietf.org/doc/html/rfc9052#section-4.4-4 >> Result is Sig_structure = [ context : "Signature1", protected_header: >> bytes, payload : 1 TB LLM Model ] >> Hash the Sig_structure with SHA-256 >> >> Send the result to a remote KMS... >> A sha-256 hash moves over the network. >> Server does not see protocol metadata / Sig_structure... cannot enforce >> policy on it. >> >> Client receives a raw HashML-DSA-65-SHA-256 signature... >> Construct a complete cose-sign1 >> >> # Case 2 >> >> With ML-DSA-65 and "COSE Hash Envelope" the client can do the following: >> >> Hash the 1 TB payload to produce a sha-256 hash. >> >> Set the protected header to be { alg: ML-DSA-65, payload_hash: SHA-256 } >> // protocol layer pre-hash >> Construct the Sig_structure as defined in >> https://datatracker.ietf.org/doc/html/rfc9052#section-4.4-4 >> Result is Sig_structure = [ context : "Signature1", protected_header: >> bytes, payload : bytes (sha-256 hash) ] >> >> Send the result to a remote KMS... >> Protocol data structure moves over the network, and is larger than >> sha-256 hash. >> Server sees the protocol metadata / Sig_structure... can enforce policy >> on it. >> >> Client receives a raw HashML-DSA-65 signature... >> Construct a complete cose-sign1 >> >> # Case 3 >> >> With HashML-DSA-65-SHA-256 and "COSE Hash Envelope" the client can do the >> following: >> >> Hash the 1 TB payload to produce a sha-256 hash. >> >> Set the protected header to be { alg: HashML-DSA-65-SHA-256, >> payload_hash: SHA-256 } // crypto and protocol layer pre hashing >> Construct the Sig_structure as defined in >> https://datatracker.ietf.org/doc/html/rfc9052#section-4.4-4 >> Result is Sig_structure = [ context : "Signature1", protected_header: >> bytes, payload : bytes (sha-256 hash) ] >> Hash the Sig_structure with SHA-256 >> >> Send the result to a remote KMS... >> A sha-256 hash moves over the network. >> Server does not see protocol metadata / Sig_structure... cannot enforce >> policy on it. >> >> Client receives a raw HashML-DSA-65-SHA-256 signature... >> Construct a complete cose-sign1 >> >> ... >> >> See Section 5.4 of FIPS204 >> >> """ >> If the content to be signed is large, hashing of the content is often >> performed at the application level. >> For example, in the Cryptographic Message Syntax [29], a digest of the >> content may be computed, and >> that digest is signed along with other attributes. If the content is not >> hashed at the application level, the >> pre-hash version of ML-DSA signing may be used. >> >> 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 [8] or FIPS 202 [7]) that provides at least >> 𝜆 bits of classical security strength >> against both collision and second preimage attacks ... >> """ >> >> In the example I gave above, I used SHA-256 for everything, but I could >> have used SHAKE256 and SHA-256 strategically to work around constraints on >> the client or the server. >> >> This is noted at the top of Section 5.4: >> >> """ >> For example, the platform may require hardware support for hashing to >> achieve acceptable performance but lack >> hardware support for SHAKE256 specifically. >> """ >> >> Regards, >> >> OS >> >> >> >> On Tue, Aug 27, 2024 at 10:30 AM Phillip Hallam-Baker < >> [email protected]> wrote: >> >> You can indeed pass the digest directly into pure. The issue being that >> it is unsafe to do so, an attacker can perform a digest substitution attack >> on it. >> >> >> >> Consider the case where the application supports a hash which has been >> broken to the extent that they can create any digest output they like - >> MD-BORKED >> >> >> >> Queen Alice decides to knight Bob, writes out a declaration to that >> effect, hashes it with SHA-2-512 and posts it to the gazette. >> >> >> >> Mallet takes the signature, writes out a death warrant for Bob and uses >> the MD-BORKED manipulation code to create a digest that matches that of the >> original message. Instead of arriving to find the Queen holding a sword to >> confer the accolade, Bob finds the headsman holding an axe. >> >> >> >> >> >> That is why it is always necessary to bind the digest type into the >> signature if a pre-hash is used. >> >> >> >> Pure should only be used on the message content itself or on a manifest >> structure which includes the digest value. >> >> >> >> So for example, a DARE signature on a chunk appended to a sequence >> typically contains the following information: >> >> >> >> * Digest algorithm used to digest the content >> >> * Digest value over the content >> >> * Digest algorithm used to create the Merkle Tree >> >> * Apex value of the Merkle tree >> >> * Witness value showing demonstrating the signer knew the encryption key >> >> * Application context identifier >> >> >> >> Those values are carried in a separate JSON manifest which once I have >> finished the code will be signed with ML-DSA pure and with Ed448 pure with >> the context string 'DARE manifest'. >> >> >> >> >> >> >> >> On Tue, Aug 27, 2024 at 7:04 AM Falko Strenzke <[email protected]> >> wrote: >> >> Dear NIST team, >> >> in FIPS 204, Section 5.4, I read >> >> >> >> >> *If the content to be signed is large, hashing of the content is often >> performed at the application level. For example, in the Cryptographic >> Message Syntax [29 ], a digest of the content may be computed, and that >> digest is signed along with other attributes. If the content is not hashed >> at the application level, the pre-hash version of ML-DSA signing may be >> used.* >> >> How is the last sentence to be understood? If the content is not hashed >> at the application level, that sounds to me as if it can be fed into the >> pure signature generation or verification routine directly. After all, >> ML-DSA signature generation and verification is single-pass over the >> message, if I am not mistaken. >> >> On the contrary, my understanding of the pre-hash variant is that it is >> specifically for those cases, where the protocol is bound to compute a hash >> before it can access (or decide on) the signature generation or >> verification function. The last sentence of the quote, however, seems to >> suggest that the pre-hash variant is merely a convenience function to >> combine the hash computation with the signature computation. >> >> Can you please clarify? >> >> Best regards, >> Falko >> >> -- >> >> *MTG AG* >> Dr. Falko Strenzke >> >> Phone: +49 6151 8000 24 <+49%206151%20800024> >> E-Mail: [email protected] >> Web: mtg.de <https://www.mtg.de/> >> >> >> <https://www.linkedin.com/search/results/all/?fetchDeterministicClustersOnly=true&heroEntityKey=urn%3Ali%3Aorganization%3A13983133&keywords=mtg%20ag&origin=RICH_QUERY_SUGGESTION&position=0&searchId=d5bc71c3-97f7-4cae-83e7-e9e16d497dc2&sid=3S5&spellCorrectionEnabled=false> >> Follow us >> ------------------------------ >> >> <https://360-german-security-alliance.de/> >> >> <https://www.itsa365.de/de-de/companies/m/mtg-ag> >> >> 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 >> <https://www.mtg.de/en/privacy-policy> >> >> -- >> 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/e619b550-178a-4816-8605-8ffb3d0e9c06%40mtg.de >> <https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/e619b550-178a-4816-8605-8ffb3d0e9c06%40mtg.de?utm_medium=email&utm_source=footer> >> . >> >> -- >> 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAMm%2BLwixu%3D7wLpOu%3D3eZAaj0BZSrDcz%2B_k6%2BAeKrRemY-j8wig%40mail.gmail.com >> <https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAMm%2BLwixu%3D7wLpOu%3D3eZAaj0BZSrDcz%2B_k6%2BAeKrRemY-j8wig%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> >> >> >> -- >> >> >> >> >> *ORIE STEELE *Chief Technology Officer >> www.transmute.industries >> >> <https://transmute.industries/> >> >> -- >> 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAN8C-_LWNnmiNSdmpkB%3D58HuhqqtbBZdgo876dikA_qJvZ97oA%40mail.gmail.com >> <https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAN8C-_LWNnmiNSdmpkB%3D58HuhqqtbBZdgo876dikA_qJvZ97oA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> -- >> 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/PH0PR02MB7430852EF75C0D0021EF4488B7962%40PH0PR02MB7430.namprd02.prod.outlook.com >> <https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/PH0PR02MB7430852EF75C0D0021EF4488B7962%40PH0PR02MB7430.namprd02.prod.outlook.com?utm_medium=email&utm_source=footer> >> . >> > > > -- > "If we were supposed to talk more than listen, we would have been given > two mouths and one ear" - Mark Twain > > "A lot of trouble will disappear if everyone learns to talk to each other > instead of talking about each other.." > > "Don't win the argument, win the person. To win the person, it is required > to understand than to explain" > > > -- > 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 [email protected]. > To view this discussion visit > https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAGEt81zeoMU1HzLBGNDC4bC0E06gmDSz-upe9T7fP58WPhFAGw%40mail.gmail.com > <https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAGEt81zeoMU1HzLBGNDC4bC0E06gmDSz-upe9T7fP58WPhFAGw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- Sophie Schmieg | Information Security Engineer | ISE Crypto | [email protected]
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
