More discussion of ExternalMu #54
Conversation
|
|
||
| The security reason for disallowing HashML-DSA is that the design of the ML-DSA algorithm provides enhanced resistance against signature collision attacks, compared with conventional RSA or ECDSA signature algorithms. Specifically, ML-DSA binds the hash of the public key `tr` to the message to-be-signed prior to hashing, as described in line 6 of Algorithm 7 of [FIPS204]. In practice, this provides binding to the 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 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. | ||
|
|
||
| The implentation reason for disallowing HashML-DSA stems from the fact 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()`, which itself introduces some risk of cross-protocol forgery attacks in some contexts. Additionally, since the same object identifiers (OIDs) are used to identify the ML-DSA public keys and ML-DSA signature algorithms, an implementation would need to commit a given public key to be either of type `ML-DSA` or `HashML-DSA` at the time of certificate creation. This is anticipated to cause operational issues in contexts where the operator does not know at key generation time whether the key will need to produce pure or pre-hashed signatures. ExternalMu-ML-DSA avoids all of these operational concerns by virtue of having keys and signatures that are indistinguishable from ML-DSA (ie ML-DSA and ExternalMu-ML-DSA are mathematically equivalent algorithms). The difference between ML-DSA and ExternalMu-ML-DSA is mererly an internal implementation detail of the signer and has no impact on the verifier. |
There was a problem hiding this comment.
I find this a little verbose and a little alarmist. The collision resistance of SHA-2 or SHAKE256 is fine. I think there is value in pointing out that HashML-DSA is a different signature than PureML-DSA which is not ideal. But ExternalMuML-DSA generates the same signature as Pure ML-DSA (same OID too), thus why we picked it.
| @@ -451,6 +453,12 @@ ExternalMu-ML-DSA.Sign_internal(sk, mu, rnd): | |||
| ~~~ | |||
| {: #fig-externalmu-ml-dsa-internal title="Internal steps of ExternalMu-ML-DSA"} | |||
|
|
|||
| There are some implementation considerations and security specific to the ExternalMu mode that are worth discussion. | |||
|
|
|||
| An additional implementation consideration imposed by ExternalMu-ML-DSA is the requirement to provide the public key, or its prehash, to the `ExternalMu-DL-DSA.Prehash()` routine. This is different from conventional pre-hashing which only requires the message and the hash function as input. This may impose additional implementation burden in order for the client that is performing the pre-hash to first obtain the public key prior to invoking the pre-hash routine. Implementions are RECOMMENDED to expose interfaces for both ML-DSA and ExternalMu-ML-DSA so that applications can manage themselves the tradeoff between ExternalMu pre-hashing when they have the public key available, and pure ML-DSA which requires streaming the entire message into the cryptographic module. | |||
There was a problem hiding this comment.
ExternalMu-DL-DSA.Prehash() - typo
- language typos... Check over.
There was a problem hiding this comment.
@johngray-dev Did you confirm there was a typo?
There was a problem hiding this comment.
I think this is getting resolved via Panos' re-write.
| @@ -451,6 +453,12 @@ ExternalMu-ML-DSA.Sign_internal(sk, mu, rnd): | |||
| ~~~ | |||
| {: #fig-externalmu-ml-dsa-internal title="Internal steps of ExternalMu-ML-DSA"} | |||
|
|
|||
| There are some implementation considerations and security specific to the ExternalMu mode that are worth discussion. | |||
There was a problem hiding this comment.
I think the entire ExternalMu-ML-DSA section should be an appendix rather than a core part of the document.
In fact, I think the entire ExternalMu-ML-DSA section shouldn't contain any normative language. It is an implementation detail which does not affect interoperability. It's not even a "mode" of signing, it IS pure ML-DSA.Sign, just split across two functions.
The point of the ExternalMu-ML-DSA section should be "If you want to perform the hashing step locally and send a digest to an HSM, FIPS 204 allows you to do that and here's explicitly how it can be done."
There was a problem hiding this comment.
I agree.
The way the ExternalMu-ML-DSA section looks right now may create misconceptions that we are defining a tweak on ML-DSA, but we are just saying "get the mu from outside of the signature".
There was a problem hiding this comment.
Whether the hash is computed internal to the ML-DSA or external is not important for interoperability. The signature comes out the same. So, I am not sure this deserves any discussion.
| @@ -451,6 +453,12 @@ ExternalMu-ML-DSA.Sign_internal(sk, mu, rnd): | |||
| ~~~ | |||
| {: #fig-externalmu-ml-dsa-internal title="Internal steps of ExternalMu-ML-DSA"} | |||
|
|
|||
| There are some implementation considerations and security specific to the ExternalMu mode that are worth discussion. | |||
|
|
|||
| An additional implementation consideration imposed by ExternalMu-ML-DSA is the requirement to provide the public key, or its prehash, to the `ExternalMu-DL-DSA.Prehash()` routine. This is different from conventional pre-hashing which only requires the message and the hash function as input. This may impose additional implementation burden in order for the client that is performing the pre-hash to first obtain the public key prior to invoking the pre-hash routine. Implementions are RECOMMENDED to expose interfaces for both ML-DSA and ExternalMu-ML-DSA so that applications can manage themselves the tradeoff between ExternalMu pre-hashing when they have the public key available, and pure ML-DSA which requires streaming the entire message into the cryptographic module. | |||
There was a problem hiding this comment.
I strongly disagree with "Implementations are RECOMMENDED to expose interfaces for both ML-DSA and ExternalMu-ML-DSA so that applications blah blah blah". ExternalMu-ML-DSA is only needed if you need to send the message representative to an HSM/smartcard/non-local-whatever. If you're writing an implementation for an HSM/smartcard/non-local-whatever then sure, implement ExternalMu-ML-DSA, but you shouldn't even need to expose ExternalMu-ML-DSA to the application, that's only something that your HSM/smartcard/non-local-whatever driver needs to know about.
There was a problem hiding this comment.
I agree. I suggest to remove the normative language here. Good to point out that the entity that does the prehashing and requests for the signature has the public key beforehand
ExternalMu-ML-DSA requires the public key, or its prehash, as input to the pre-digesting function. This assumes the signer generating the pre-hash is in possession of the public key before signing and is different from conventional pre-hashing which only requires the message and the hash function as input and .
There was a problem hiding this comment.
I see no reason for this document to get into the API discussion. Just drop the text altogether about "... Implementations are RECOMMENDED to expose interfaces ..."
|
See #65. |
I added some more implementation and security considerations as well as the rationale for disallowing HashML-DSA, which I feel needs to be stated clearly (this comes from recent IETF and pqc-forum mail list discussions).