Question regarding pure vs. pre-hash ML-DSA

[Falko Strenzke]

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
E-Mail: falko.s...@mtg.de
Web: mtg.de

Follow us

---

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

[Phillip Hallam-Baker]

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'.

--
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/e619b550-178a-4816-8605-8ffb3d0e9c06%40mtg.de.

[Orie Steele]

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

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.

--

ORIE STEELE
Chief Technology Officer
www.transmute.industries

[Falko Strenzke]

Thanks for the pointer. If I see it correctly you are suggesting a pre-image attack on a hash algorithm that is accepted by the recipient. Pre-image attacks are not a known threat for any hash algorithm still potentially in use, not even MD5, as far as I know, but it's certainly a valid concern to hedge against this possibility. This would be the reason why the pre-hash variant hashes the hash OID internally. This is all the more showing how important correct use of the two variants is and is thus reinforcing my question.

My question to NIST actually isn't about technical matters regarding the security properties of hash algorithms, I am asking how NIST intends the quoted text is to be understood that is part of their guidance on using the pre-hash variant.

The meaning of the sentence following in the next paragraph is also not clear to me: "In order to maintain the same level of security strength when the content is hashed at the application level or using HashML-DSA [...]" This seems to suggest that the content may be hashed at the application level and then the hash signed with the pure variant. (That is implied by the "or" connecting the two clauses.) Possibly here it is referred to a case like that of CMS where the signedAttrs may be signed and where the message digest is contained in that object. But I think that doesn't become clear. My recent experience in a discussion is that this paragraph can be understood to counter the clear statement at the beginning of section 5.4:

For some use cases, this may be addressed by signing a digest of the message along with some domain separation information rather than signing the message directly. This version of ML-DSA is known as “pre-hash” ML-DSA or HashML-DSA.

Best regards,
Falko

Am 27.08.24 um 17:29 schrieb Phillip Hallam-Baker:

[Falko Strenzke]

Hi Dustin,

in that case let me formulate the most relevant question that we are facing in OpenPGP currently, that was my main motivation for understanding the quoted paragraphs:

OpenPGP is committed to the hash-and-sign paradigm. RFC 9580, the current specification, throughout describes how data is first hashed and then signed. When introducing ML-DSA and SLH-DSA to OpenPGP, we are bound to this approach. The question now is: In such a case, is it a NIST approved solution, to use the pure variants of both PQC schemes to sign the hash value?

Best regards,
Falko

Am 28.08.24 um 18:00 schrieb Moody, Dustin (Fed):

Falko,

We're trying to answer your question, but we don't quite get the point you're making, which makes it hard to respond.  Can you try explaining it to me again, as clearly as possible so we understand?   The text seems pretty straightforward to us.  

Dustin

---

From: pqc-...@list.nist.gov on behalf of Falko Strenzke
Sent: Wednesday, August 28, 2024 12:41 AM
To: Phillip Hallam-Baker
Cc: pqc-forum
Subject: Re: [pqc-forum] Question regarding pure vs. pre-hash ML-DSA

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/f1447b2b-b72e-40be-b4ed-df6b28ae6867%40mtg.de.

--

MTG AG
Dr. Falko Strenzke

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

[Michael Jones]

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: pqc-...@list.nist.gov <pqc-...@list.nist.gov> On Behalf Of Orie Steele
Sent: Tuesday, August 27, 2024 9:32 AM
To: Phillip Hallam-Baker <ph...@hallambaker.com>
Cc: Falko Strenzke <falko.s...@mtg.de>; pqc-forum <pqc-...@list.nist.gov>; cose <co...@ietf.org>
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:

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.

[David A. Cooper]

Hello Falko,

The text in Section 5.4 of FIPS 204 and Section 10.2 of FIPS 205 just attempts to explain the reason that both "pure" and "pre-hash" versions. I'm not familiar with OpenPGP, but it seems like this is a case where either version could be used.

From my reading of Section 5.2.4 of  RFC 9580, the content that is signed is what is referred to as a trailer. In the case of RSA and ECDSA, the trailer is signed directly. The text may describe hashing the trailer first and then generating a signature from that hash, but the result is the same as just signing the trailer. Section 6.1.1 of https://www.ietf.org/archive/id/draft-ehlen-openpgp-nist-bp-comp-00.html notes that an ECDSA signature is created by computing a hash of M and then performing ECDSA.Sign() on that hash, but "excluding Step 1: H = Hash(M) in [the FIPS 186-5 ECDSA] algorithm specification." So, the result is the same as signing M with ECDSA using the specified hash algorithm. The description for RSA in RFC 9580 is essentially the same.

With EdDSA, however, Section 12.7 of RFC 9580 states to use PureEdDSA to sign the hash of the trailer. So, unlike with RSA and ECDSA, from the signature algorithm's point of view it is the hash of the trailer that is signed. HashEdDSA could have been used to sign the trailer, but that was not the decision that was made. (Perhaps the reason is that with HashEdDSA, RFC 8032 would have dictated which hash function to use.)

With ML-DSA and SLH-DSA, you could either create a pre-hash signature of the trailer (which would align with how RSA and ECDSA work in RFC 9580) or a pure signature of the hash of the trailer (which would align with how EdDSA works in RFC 9580). Phillip noted that the pre-hash version signs the identifier of the hash function, preventing a potential hash algorithm substitution attack. However, the trailer seems to already include an identifier for the hash function, so a pure signature of the hash of the trailer would already be protected from such an attack.

Follow us

---

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

--

[Falko Strenzke]

Hi David,

thanks for the detailed answer. As the most important point, I take away that using the pure variant of ML-DSA to sign a hash would at least not preclude to achieve NIST conformance.

As a note: I came to the conclusion that the use of ML-DSA in OpenPGP solves all the potential security problems that are connected with using the pure variant to sign a hash instead of signing the message directly:

- OpenPGP v6 signatures (to which the use of ML-DSA is bound) prefix a random salt at the beginning of the hashed data, thus effectively preventing the exploitation of a collision vulnerability in the hash function,
- the message digest algorithm is fixed for each ML-DSA parameter set, thus effectively preventing the digest substitution attacks that Phillip pointed out.

See further comments inline.

Am 29.08.24 um 21:05 schrieb David A. Cooper:

Hello Falko,

The text in Section 5.4 of FIPS 204 and Section 10.2 of FIPS 205 just attempts to explain the reason that both "pure" and "pre-hash" versions. I'm not familiar with OpenPGP, but it seems like this is a case where either version could be used.

From my reading of Section 5.2.4 of  RFC 9580, the content that is signed is what is referred to as a trailer. In the case of RSA and ECDSA, the trailer is signed directly. The text may describe hashing the trailer first and then generating a signature from that hash, but the result is the same as just signing the trailer. Section 6.1.1 of https://www.ietf.org/archive/id/draft-ehlen-openpgp-nist-bp-comp-00.html notes that an ECDSA signature is created by computing a hash of M and then performing ECDSA.Sign() on that hash, but "excluding Step 1: H = Hash(M) in [the FIPS 186-5 ECDSA] algorithm specification." So, the result is the same as signing M with ECDSA using the specified hash algorithm. The description for RSA in RFC 9580 is essentially the same.

Yes, this is what we intended to describe here.

With EdDSA, however, Section 12.7 of RFC 9580 states to use PureEdDSA to sign the hash of the trailer. So, unlike with RSA and ECDSA, from the signature algorithm's point of view it is the hash of the trailer that is signed. HashEdDSA could have been used to sign the trailer, but that was not the decision that was made. (Perhaps the reason is that with HashEdDSA, RFC 8032 would have dictated which hash function to use.)

That is also how I understand RFC 8032. As a note: the trailer you mention is only the last part of the signed / hashed data, before it the signed document or packet(s) is hashed.

With ML-DSA and SLH-DSA, you could either create a pre-hash signature of the trailer (which would align with how RSA and ECDSA work in RFC 9580) or a pure signature of the hash of the trailer (which would align with how EdDSA works in RFC 9580). Phillip noted that the pre-hash version signs the identifier of the hash function, preventing a potential hash algorithm substitution attack. However, the trailer seems to already include an identifier for the hash function, so a pure signature of the hash of the trailer would already be protected from such an attack.

Regarding the last sentence: No, in general, if the hash algorithm identifier is part of what is hashed, then it will also be subject to the substitution attack. For this purpose, the algorithm ID must be part of either the data fed into pure-ML-DSA-sign() as the signed data or the ctx parameter. (As stated above, this does not apply for OpenPGP in particular.)

Best regards,
Falko

[Simo Sorce]

Hello David,
your response mentions that both "pure" and "pre-hash" variants would
be ok for openpgp.

The spec expresses a recommendation to use Pure ML-DSA (quoting: `In
general, the “pure” ML-DSA version is preferred.`) and this has been
taken, by some, to mean that applications should prefer the use of ML-
DSA even when the content being signed is pre-hashed.

Can you clarify if NIST would recommend the use of HashML-DSA when the
message is pre-hashed, all else equal?

Or would NIST recommend to use the pure ML-DSA, regardless of what form
the message takes and relegates HashML-DSA just to cases where there is
a technical deficiency in the Crypto module implementation that makes
pure ML-DSA impractical for large messages ?

Thank you,
Simo.

On Thu, 2024-08-29 at 12:05 -0700, 'David A. Cooper' via pqc-forum
wrote:

> > > ------------------------------------------------------------------------
> > > *From:* pqc-...@list.nist.gov on behalf of Falko Strenzke
> > > *Sent:* Wednesday, August 28, 2024 12:41 AM
> > > *To:* Phillip Hallam-Baker
> > > *Cc:* pqc-forum
> > > *Subject:* Re: [pqc-forum] Question regarding pure vs. pre-hash ML-DSA

> > >
> > > Thanks for the pointer. If I see it correctly you are suggesting a
> > > pre-image attack on a hash algorithm that is accepted by the
> > > recipient. Pre-image attacks are not a known threat for any hash
> > > algorithm still potentially in use, not even MD5, as far as I know,
> > > but it's certainly a valid concern to hedge against this possibility.
> > > This would be the reason why the pre-hash variant hashes the hash OID
> > > internally. This is all the more showing how important correct use of
> > > the two variants is and is thus reinforcing my question.
> > >
> > > My question to NIST actually isn't about technical matters regarding
> > > the security properties of hash algorithms, I am asking how NIST
> > > intends the quoted text is to be understood that is part of their
> > > guidance on using the pre-hash variant.
> > >
> > > The meaning of the sentence following in the next paragraph is also

> > > not clear to me: "/In order to maintain the same level of security

> > > strength when the content is hashed at the application level or using

> > > HashML-DSA [...]/" This seems to suggest that the content may be

> > > hashed at the application level and then the hash signed with the
> > > pure variant. (That is implied by the "or" connecting the two
> > > clauses.) Possibly here it is referred to a case like that of CMS
> > > where the signedAttrs may be signed and where the message digest is
> > > contained in that object. But I think that doesn't become clear. My
> > > recent experience in a discussion is that this paragraph can be
> > > understood to counter the clear statement at the beginning of section
> > > 5.4:
> > >

> > > /For some use cases, this may be addressed by signing a digest of the

> > > message along with some domain separation information rather than
> > > signing the message directly. This version of ML-DSA is known as

> > > “pre-hash” ML-DSA or HashML-DSA./

> > > /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
> > > E-Mail:

> > > falko.s...@mtg.de <mailto:falko.s...@mtg.de>
> > > Web:
> > > mtg.de
> > > <https://www.mtg.de/>
> > > Follow us
> > > ------------------------------------------------------------------------

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

> > > <mailto: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/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>.
> > >
> > >
>

--
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc

[David A. Cooper]

Hello Simo,

I'm not a cryptographer and only skimmed through the OpenPGP specs, but
it does seem that either version would be okay. Falko is correct that I
was mistaken in thinking including the hash identifier in the trailer
would protect against hash substitution attacks, as including the
identifier provides no protection if the verifier is willing to accept a
hash function that is so broken that an attack can find a second
pre-image. However, if the hash function is dictated by the
specification, then that should prevent such an attack.

I can only speak for myself, not for NIST. I think with respect to
OpenPGP, the question is somewhat different than you are phrasing it. As
I noted in my message to Falko, OpenPGP is effectively taking two
different approaches to signing, depending on whether RSA, ECDSA, or
EdDSA is being used. With RSA and ECDSA the message that is signed is
the trailer. With EdDSA the message that is signed is the hash of the
trailer. So, with respect to OpenPGP, you seem to be asking which of
those two options is better.

The text in the FIPS doesn't consider that. The FIPS assumes that the
same message would be passed to either ML-DSA.Sign or HashML-DSA.Sign,
with the latter performing an extra hash.

I do not think of HashML-DSA.Sign as being a case in which the hashing
of the message occurs at the application level. I think of the way that
signing works with my smart card (or an HSM) now. If my application
wants to sign a message (using RSA or ECDSA), calls a sign function of
the cryptographic library. The library sends the message to a software
cryptographic module (that is probably statically or dynamically linked
to the cryptographic library), applies any necessary padding to the
hash, and then sends the result to the smart card (or HSM), which
performs the private key operation. I would expect something similar
with ML-DSA. The application just asks for a message to be signed. The
cryptographic library handles the details of how to do that, which may
involve sending different commands to different cryptographic modules.

In most cases when the content to be protected is large and hashing
occurs at the application level, the message that is signed isn't just a
hash. In the case of the Cryptographic Message Syntax (CMS), the message
that is signed consists of the message digest, message digest
identifier, and possibly other attributes (e.g., signing time). The
resource PKI does something similar with manifests (Section 4.2 of RFC
6486). I believe other formats similarly include some metadata along
with the digest of the information being protected.

So, when the FIPS says that the pure variant is preferred, it just means
that to compute a signature on M, it is preferred to use ML-DSA.Sign
over HashML-DSA.Sign. It doesn't mean that it is preferred to compute a
pure signature of Hash(M) rather than computing a pre-hash signature of M.

[Simo Sorce]

On Fri, 2024-08-30 at 14:08 -0700, David A. Cooper wrote:
> So, when the FIPS says that the pure variant is preferred, it just means
> that to compute a signature on M, it is preferred to use ML-DSA.Sign
> over HashML-DSA.Sign. It doesn't mean that it is preferred to compute a
> pure signature of Hash(M) rather than computing a pre-hash signature of M.

Thanks,
this is all I really wanted to understand.

Simo.