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
| indended verification public key, preventing some attacks that would | ||
| otherwise allow a signature to be successfully verified against a | ||
| non-intended public key. Also, this binding means that in the case of | ||
| the discovery of a collision attack against SHA-3, an attacker would |
There was a problem hiding this comment.
"unlikely discovery of a collision attack ..."
| non-intended public key. Also, this binding means that in the case of | ||
| the discovery 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 |
There was a problem hiding this comment.
Remove "simple". Finding a collision on a good hash functions should not be considered simple.
| 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.
| different `Verify()` routines. This forwards to the protocol the | ||
| complexity of informing the client whether to use `ML-DSA.Verify()` or | ||
| `HashML-DSA.Verify()`, which itself introduces some risk of | ||
| cross-protocol forgery attacks in some contexts. Additionally, since |
There was a problem hiding this comment.
"cross-protocol forgery attacks in some contexts"?
The OID and the ctx in M' are preventing those. I suggest to remove
" which itself introduces some risk of cross-protocol forgery attacks in some contexts"
| assumptions of the ML-DSA algorithm. Implementors should 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. Note that HashML-DSA also weakens this security assumption even |
There was a problem hiding this comment.
Remove the mention to HashML-DSA, it is covered already in the Security Considerations.
| will independently compute `tr` from the public key. Second, a malicious | ||
| or tricked signer could potentially produce a signature which validates | ||
| under a different public key, which weakens the implicit security | ||
| assumptions of the ML-DSA algorithm. Implementors should pay careful |
There was a problem hiding this comment.
Remove
Second, a malicious or tricked signer could potentially produce a signature which validates under a different public key, which weakens the implicit security assumptions of the ML-DSA algorithm.
Alarmist. You can fool the signer that generates tr to use a different public key, but then you would also need to fool the rest of the signing to use a different private key. It means you control the whole signature generation which means you can do anything.
The next sentence is fine though. tr should be generated with a public key we can trust regardless of how it is to exploit it.
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.