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

[Simo Sorce <[e-mail]>]

On Fri, 2024-08-30 at 07:18 +0000, Daniel Huigens wrote:
> 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 do not understand how you come to the conclusion I do not understand
the purpose of HashML-DSA given that purpose is clearly stated in
FIPS204.

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

Can you quote FIPS204 to substantiate this position? I quoted it
literally to support my position.


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

I quoted the literal text that says (paraphrasing) "the application can
provide PHM", I do not understand how you can make this contentious. It
is written right there.

> > 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)

Yes, and I think this is where you misunderstand the context I think.

This phrase allows you to use the pore-hash version *also* in the case
the application gives you a full message, if the cryptographic module
can use a much faster hashing mechanisms separate from the one used
within the internal signing function. It is meant as an enabling and
not an excluding condition.

IE you are not force to use Pure ML-DSA if your devices are constrained
and HashML-DSA would be a more efficient way to implement this.


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

And this is relevant how?

NIST sets the FIPS standards, all this is saying is that even if the
application is doing the pre-hash, the hashing function should still be
a FIPS validated implementation. They go to great length to specify
that this hashing function can be validated in an entirely different
FIPS module, exactly to avoid paperwork obstacles.

It just corroborates the interpretation I am giving you that you can do
that hash elsewhere, specifically by the application before passing PHM
into the cryptographic module.

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

Yes, this is what it is saying, so how is this contradicting anything
about what I said about HashML-DSA and its appropriateness?

> > for the non-FIPS language versed "Outside the cryptographic module" ==
> > "The application"
> 
> So no, in this case they mean "in a different cryptographic module".

Your are playing with semantics, I certify software implementations of
cryptographic modules as my day job, In RHEL, we have 4 different
libraries certified that can do hashes, and all our applications
(including PGP implementations) use one of those *certified* modules to
do the Hashing. Certified cryptographic modules are not just *hardware*
modules.

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

I am not sure why you insist quoting this sentence. YEs NIST prefers
Pure ML-DSA where possible, but "pure" Ml-DSA'a premise is tat you pass
the whole content you want to sign into it.

You are clearly do not want to do that, you want to pass in pre-hashed
content, so you clearly fall into the pre-hash category which is served
by HashML-DSA.


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

You are treating an inclusive or like an exclusive or here. This text
just says that even if the cryptographic module is given a full
message, the implementation can  still decide to use the pre-hash
variant instead of the pure one, for internal convenience reasons.

This text has nothing to do with application that use pre-hashing so it
is irrelevant to establish what is the correct function to use for
openpgp.

> 
> Btw, if your position is that you _disagree_ with NIST and/or FIPS 204,

I disagree with your interpretation, because I think your
interpretation is faulty. You are reading preferences and requirements
that are not there, and coming up to a conclusion which is the exact
opposite of what the spec would recommend you to do.

This is why I am debating your statements.

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

So I think you misread the spec, and clearly you think I misread it.
Perhaps we bring the case to NIST and ask them what they think?

Simo.

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