enable ML-DSA external mu via signDigest/verifyDigest

[panva]

A companion proposal to (and making use of) w3c/webcrypto#551 for ML-DSA.

---

Preview | Diff

[twiss]

Thanks!

Similarly to w3c/webcrypto#551 (comment), I would prefer to define separate algorithms "HashML-DSA-{44,65,87}", to be explicit about the algorithm that's used; and additionally because FIPS 204 states that:

While a single key pair may be used for both ML-DSA and HashML-DSA signatures, it is recommended that each key pair only be used for one version or the other.

So, to nudge the use of the API towards that, having separate algorithms makes it slightly harder to reuse a key across ML-DSA and HashML-DSA, since you'd need to import it for each algorithm separately.

Finally, also here I don't think HashML-DSA is actually used much?

[panva]

The goal isn't HashML-DSA per se, it's external mu, so a hard -1 on a separate algorithm, this is about external mu and HashML-DSA just happens to be achievable by having external mu capability which is why it is mentioned.

[panva]

87d4b5a would be the equivalent of https://docs.openssl.org/master/man7/EVP_MD-ML-DSA-MU/

But personally I don't think it's needed. It is a nice to have as the mu computation can be a bit challenging but it's totally possible with the existing algorithms already. So it's a shortcut.

[twiss]

Ah sorry, from the mention of HashML-DSA I thought the proposal was to pass the digest to Sign_internal as M' (rather than μ), i.e. like HashML-DSA does. (To implement HashML-DSA you don't need external-mu, having Sign_internal as specified is sufficient.)

However, I'm also not super sure that ML-DSA with external-mu is really necessary to expose; because it's perfectly secure to pass a digest to ML-DSA (as a message), and then let ML-DSA hash it again, which is what CMS and OpenPGP ended up doing, for example. With proper usage of contexts, you can also distinguish between signing a message and signing a digest (as well as indicate which hash algorithm was used).