ExternalMu Shuffle #65
Conversation
Moved " Pre-hash Mode" section to an Appendix. There are editorial tweaks, but more importantly 2119 language is removed from the Appendix. I want to call attention to the four (4) 2119 language changes: * reworked some of this into Security Considerations: This specification uses exclusively ExternalMu-ML-DSA for pre-hashed use cases, and thus HashML-DSA as defined in [FIPS204] and identified by `id-hash-ml-dsa-44-with-sha512`, `id-hash-ml-dsa-65-with-sha512`, and `id-hash-ml-dsa-87-with-sha512` MUST NOT be used in X.509 and related PKIX protocols. * Implementions are RECOMMENDED -> whole paragraph re-written. * An ML-DSA key and certificate [MAY->can] be used with either ML-DSA or ExternalMu-ML-DSA interchangeably. * Implementors [SHOULD->should] to pay careful attention to how the public key or its hash is delivered to the `ExternalMu-ML-DSA.Prehash()` routine, and from where they are sourcing this data.
seanturner
requested review from
bwesterb,
ounsworth,
danvangeest and
johngray-dev
| message pairs such that `H(tr || m1) = H(tr || m2)` since a simple hash | ||
| collision `H(m1) = H(m2)` will not suffice. HashML-DSA removes both of | ||
| these enhanced security properties and therefore is a weaker signature | ||
| algorithm. |
There was a problem hiding this comment.
Remove "therefore is a weaker signature algorithm." In practice it is not weaker because SHA-3 does not have collisions. Better to not be too alarmist.
There was a problem hiding this comment.
Is there a less alarmist wording that still captures the same idea?
Maybe "... and therefore weakens some of the security properties built in to the ML-DSA design" ?
There was a problem hiding this comment.
I am proposing the below rephrase
[...] Also, this binding means that in the unlikely, theoretical case of a collision attack against SHA-3, an attacker would have to perform a public-key-specific collision search in order to find message pairs such that H(tr || m1) = H(tr || m2) since a simple hash collision H(m1) = H(m2) will not suffice. HashML-DSA removes both of these enhanced security properties.
and therefore is a weaker signature algorithm.
There was a problem hiding this comment.
I think the length and order of paragraphs gives undue emphasis to the security aspect. I don't mind mentioning the difference, but it should be toned down.
There was a problem hiding this comment.
Concretely, can we move the security paragraph second?
| that ML-DSA and HashML-DSA are incompatible algorithms that require | ||
| different `Verify()` routines. This forwards to the protocol the | ||
| complexity of informing the client whether to use `ML-DSA.Verify()` or | ||
| `HashML-DSA.Verify()`. Additionally, since |
There was a problem hiding this comment.
Also there is a hash that has to be specified in HashML-DSA.
|
Apart from the comments I left just now, I'm ok with this change. It's still a bit wordy, but not too bad. |
Moved " Pre-hash Mode" section to an Appendix.
There are editorial tweaks, but more importantly 2119 language is removed from the Appendix. I want to call attention to the four (4) 2119 language changes:
id-hash-ml-dsa-44-with-sha512,id-hash-ml-dsa-65-with-sha512, andid-hash-ml-dsa-87-with-sha512MUST NOT be used in X.509 and related PKIX protocols.ExternalMu-ML-DSA.Prehash()routine, and from where they are sourcing this data.Also, if this PR is adopted we can close #54.