[CFRG] Re: Prehashing in EdDSA vs ML-KEM

[Daniel Huigens <[e-mail]>]

Hi Phillip,

On Thursday, August 29th, 2024 at 18:55, Phillip Hallam-Baker wrote:

> There is a lot of confusion among implementers of [ML-DSA] and the difference between the 'pure' and 'prehash' versions. While working on my implementation, I am now convinced we just got it wrong in Ed25519 and Ed448 which do things differently.

I personally think a lot of the confusion comes from assumptions people are making about what the pure and prehash versions are meant to be used for, that contradict what's actually stated in the specs (both FIPS 204 and RFC 8032).

> The objective of [HashML-DSA] is to prevent a digest substitution attack by binding the digest algorithm to the message digest. What it is doing in effect is to create a manifest, prefixing a flag saying 'manifest' and signing that with ML-DSA-Internal.
>
> The objective of ML-DSA PURE is to allow direct access to ML-DSA-Internal to sign messages when the content hasn't been prehashed already.

That's not quite what FIPS 204 says, in fact it almost says the opposite:

> If the content is not hashed at the application level, the pre-hash version of ML-DSA signing may be used.

which also implies that if the content has been hashed at the application level, the pure version of ML-DSA should (or must?) be used.

For binding the hash algorithm that was used to the (pure) ML-DSA signature, the context parameter could be used as you suggested in the OpenPGP thread, so using HashML-DSA isn't actually necessary for that. And the spec also says:

> In general, the “pure” ML-DSA version is preferred.

This is similar to RFC 8032, by the way, which says:

> The Ed25519ph and Ed448ph variants are prehashed. This is mainly
> useful for interoperation with legacy APIs, since in most of the
> cases, either the amount of data signed is not large or the protocol
> is in the position to do digesting in ways better than just
> prehashing (e.g., tree hashing or splitting the data). The
> prehashing also makes the functions greatly more vulnerable to
> weaknesses in hash functions used. These variants SHOULD NOT be
> used.
> (...)
> In summary, if a high 128-bit security level is enough, use of
> Ed25519 is RECOMMENDED; otherwise, Ed448 is RECOMMENDED.

In other words, it is recommended that the protocol preprocesses the data in some way if necessary (although preferably by tree hashing or chunking, in the eyes of this text) and then uses PureEdDSA, rather than using HashEdDSA.

For Ed448, the context parameter can be used to prevent domain confusion, same as for ML-DSA. Pure Ed25519 unfortunately doesn't have a context parameter, so in that case protocols/applications need to be careful not to reuse a key for signing both content and hash digests, but that's usually not a huge ask.

So, even though I think it's a bit confusing that both FIPS 204 and RFC 8032 introduce variants that they then recommend not to be used, I don't think there's any huge issue here that needs fixing.

Best,
Daniel

---

Daniel Huigens
Cryptography Team LeadProton AG