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

[Daniel Huigens <[e-mail]>]

Hi Phillip,

On Saturday, August 31st, 2024 at 04:45, Phillip Hallam-Baker wrote:

> So given content <content> there are three options. (...)
> C) Signature = MLDSApre (sk, Digest(content), DigestAlg)
> (...)
> For EdDSA, the choices are (...)
> C) Signature = EdDSApre (sk, Digest(content)) WHERE Digest MUST be the one specified.

FIPS 204 and RFC 8032 don't describe the prehash variants in terms of passing a digest, they describe it in terms of passing a message and having the signing function hash it an extra time (before passing it to the "internal" signing function).

And, when implemented that way, there's no risk of using the wrong hash algorithm (in the case of HashEdDSA), or having a mismatch between the hash algorithm used and the OID passed to the internal signing function (in the case of HashML-DSA).

> I don't think C is remotely practical. I think implementations will end up picking their own content digest. So either they use a manifest format or it will end up failing.

Most implementations of HashEdDSA I've seen either accept a message (as specified), or explicitly mention that a SHA-512 hash digest should be passed. So hopefully most callers do this correctly.

Additionally, for ML-DSA and Ed448, there's another option, as you also mentioned before:

D) Signature = {ML-DSA,Ed448}(sk, SHA3-512(content), context = "SHA3-512 hash of <content> for MyAwesomeProtocol")

... and that could work not only for OpenPGP, but seems like a sensible solution to me in general.

The theoretical downside of option B (signing a manifest without a context parameter) is that you could reuse the manifest as a message if you have another context where a message is signed directly with the same key (which I think is usually unlikely, but is the only situation where any of this matters much in the first place).

Best,
Daniel