[openpgp] Re: pure vs. pre-hash in FIPS 204 and 205

[Daniel Huigens <[e-mail]>]

Hi Simo,

You're making an argument that goes roughly as follows:

- I don't understand the purpose of HashML-DSA as described in FIPS 204
- Therefore I assume the purpose must be something else, and interpret
  the text of FIPS 204 differently to fit that assumption
- The purpose I assume is the one that would be relevant for OpenPGP
- Therefore we should use HashML-DSA for OpenPGP

IMHO, this is faulty reasoning. If you don't understand the purpose
of HashML-DSA, that's fine. I don't see it as my job to justify the
existence of HashML-DSA for something other than being used in OpenPGP.
For all I care it might be completely useless and nobody implements it,
like what happened with the pre-hash variants of EdDSA.

In any case I prefer to take the text in FIPS 204 at face value, and
the straightforward reading of the text says that we shouldn't use it.


> The explanation in 5.4, the whole point of providing a pre-hash ML-DSA
> version is to allow application to doh!) "pre" Hash the message.

That's not what it says. It says: "Like ML-DSA, the signing algorithm of
HashML-DSA takes the content to be signed, the private key, and a
context as input, as well as a hash function or XOF that is to be used
to pre-hash the content to be signed."
So it's the HashML-DSA function itself that pre-hashes the content.

> What would be the point of doing that, and then re-hashing the whole
> thing a second time ? (and then a third time internally).

Indeed you wouldn't. That's why it says "If the content is *not* hashed
at the application level, the pre-hash version of ML-DSA signing may be
used." (emphasis mine)

> If you are still unconvinced look at the text at the bottom of Page 20
> which says explicitly: "As with the pre-hash signature generation, 𝑀 ′
> may be constructed outside of the cryptographic module that performs
> ML-DSA.Verify_internal."

The text after your quote continues "However, in the case of HashML-DSA,
the hash or XOF of the content must be computed within a FIPS 140-
validated cryptographic module, which may be a different cryptographic
module than the one that performs ML-DSA.Verify_internal."

Like I said, you might have a "core cryptographic module" that's on an
HSM, and a different cryptographic module that computes the hash.

> for the non-FIPS language versed "Outside the cryptographic module" ==
> "The application"

So no, in this case they mean "in a different cryptographic module".

> I know that OpenPGP does not do that, but NIST puts down general rules
> to follow that cover all cases. That is the spirit of the
> specification, and yes if you "hold it right" you can be safe using
> Pure ML-DSA, but why go against the spirit and the recommendation of
> the spec when it is rather easy to actually follow the spec and use the
> correct function which is HashML-DSA ?

You still haven't actually quoted a recommendation of the spec.
The only relevant recommendation I see is: "In general, the “pure”
ML-DSA version is preferred."

> They would not have made available HashML-DSA if there weren't
> legitimate cases for it.

Like the text I quoted above says, "If the content is not hashed at the
application level, the pre-hash version of ML-DSA signing may be used."
So the exact opposite case of OpenPGP.


Btw, if your position is that you _disagree_ with NIST and/or FIPS 204,
like some parts of your email seem to suggest, that's perfectly fine,
but that's something entirely different than claiming that the spec
recommends something different than what it actually recommends.

Best,
Daniel