Regarding Prehash in ML_DSA

[Jeevanjeet Dash]

Hi all,

I would like to confirm our approach regarding ML-DSA implementation. If we are planning to implement Hash-ML-DSA-Sign (Algorithm 4), do we also need to implement the standard ML-DSA-Sign (Algorithm 2), or is Algorithm 4 sufficient on its own?

Thanks & Regards

Jeevanjeet

[niux_d...@icloud.com]

A stand-alone implementation of Algorithm 4 doesn't require Algorithm 2 - Algorithm 7 (along with necessary steps to encode the context string and the message) is the necessary and sufficient dependency for Hash-ML-DSA-Sign.

--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAKODwQjMkM6Oz%3DBpkpAKwB2iwQ7vCFrpuJ15o8BWptaBy1DPOg%40mail.gmail.com.

[John Mattsson]

An alternative option is to implement ML-DSA-Sign (Algorithm 2) and let the signed message be (mostly) a hash, calculated with your favorite legacy hash function. This is what IETF and CNSA 2.0 seem to recommend when you cannot use SHAKE256. If you can use SHAKE256, the preferred way to do external hashing is to just use external-μ, which is just a variant of ML-DSA-Sign (Algorithm 2).

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

Cheers,
John

 

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/19C12AE9-6592-4D80-824B-534DF9E927EA%40icloud.com.

[Mike Ounsworth]

+1 to John,

Although I would re-phrase it as:

If you can use SHAKE256, the preferred way to do external hashing is to just use external-μ, which is just a variant of ML-DSA-Sign (Algorithm 2) and produces signatures which are indistinguishable from "normal" ML-DSA signatures; ie whether the signer does "normal" ML-DSA or external-µ ML-DSA is internal detail of the signer.

If you cannot use SHAKE256, then let the signed message be (mostly) a hash, calculated with your favorite legacy hash function. This, however is a "protocol change" since the verifier will need to know how the signer computed the pre-hashed message so that it can take the same steps while verifying.

---

Mike Ounsworth

 

---

From: 'John Mattsson' via pqc-forum <pqc-...@list.nist.gov>
Sent: Thursday, September 11, 2025 7:03 AM
To: niux_d...@icloud.com <niux_d...@icloud.com>; Jeevanjeet Dash <dashjee...@gmail.com>
Cc: pqc-...@list.nist.gov <pqc-...@list.nist.gov>
Subject: [EXTERNAL] Re: [pqc-forum] Regarding Prehash in ML_DSA

An alternative option is to implement ML-DSA-Sign (Algorithm 2) and let the signed message be (mostly) a hash, calculated with your favorite legacy hash function. This is what IETF and CNSA 2. 0 seem to recommend when you cannot use SHAKE256. 

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

Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.