Regarding the memory consumption challenge specifically, we've documented an optimization in draft-ietf-pquip-pqc-hsm-constrained-03 (Section 3.2) <https://www.ietf.org/archive/id/draft-ietf-pquip-pqc-hsm-constrained-03.html#section-3.2>. It aligns with the second case (where a digesting party computes the external µ), providing a way to handle large messages without requiring the signing party to buffer the entire input.
-Tiru On Tue, 27 Jan 2026 at 02:45, Sophie Schmieg <sschmieg= [email protected]> wrote: > 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] >
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
