Update draft-lundberg-cose-two-party-signing-algs.md#20
Update draft-lundberg-cose-two-party-signing-algs.md#20sophieschmieg wants to merge 1 commit intoYubicoLabs:mainfrom
Conversation
Added suggestions and comments
selfissued
left a comment
selfissued
left a comment
There was a problem hiding this comment.
This provides valuable contextual information. Thanks @sophieschmieg.
emlun
left a comment
emlun
left a comment
There was a problem hiding this comment.
Thanks! I'll work on integrating these additions into the text.
| } | ||
| ~~~ | ||
|
|
||
| COMMENT(sschmieg): For ML-DSA, we have external-µ, which is again a different API in the sense that the digester needs to be aware of the public key. We also have a context argument, but the signer does not need to learn it. |
There was a problem hiding this comment.
Hm, I don't think external-mu would need a COSE_Sign_Args. Indeed the digester needs to know the public key, but COSE_Sign_Args is meant for sending arguments from the digester to the signer. I'd say a split signing API for external-mu ML-DSA would just expose ML-DSA.Sign_internal(sk_id, mu), and have the signer sample rnd internally. So that's still just one message argument.
ctx would need a COSE_Sign_Args, but indeed it's irrelevant with external-mu. We did have ctx-ful HashML-DSA in draft -01, though, as an example of an algorithm that would need COSE_Sign_Args (then COSE_Key_Ref).
| COMMENT(sschmieg): Forgeries are *probably* okay: There is a relatively trivial forgery attack against prehashed RSA and we all seem to be fine with it. | ||
| In particular, if the digester wants to forge a signature for m, they compute h(m) (including padding), find to integers a, b such that a * b = h(m) mod n, and have the signer sign both a and b, i.e. | ||
| compute a^d and b^d. Since exponentiation is multiplicative, the digester can now compute h(m)^d, a valid signature of m, without ever having asked the signer to sign h(m). | ||
| The reason we are usually okay with that issue is that the digester already can ask the signer for any signature they want. |
There was a problem hiding this comment.
Agreed. Something like this is what I was trying to say in the "Protocol-Level Trusted Roles" section. I'm surprised I didn't spell it out as explicitly as you're doing here, we should do that too. Thanks!
| Key compromise attacks on the other hand have to be avoided. A naively prehashed version of Falcon would allow such a key compromise: A Falcon signature is a value s such that both s and s * h - hash(r || m) are short. | ||
| (h is the public key and r a randomizer). If the digester gets to query the signer for signatures of arbitrary stand-ins for hash(r || m), they can extract the private key by for example asking for repeated signatures of 0. | ||
| The basic construction of Falcon and RSA is the same (they are both hash-then-sign algorithms), but where leaving the hash to an external party only gives forgery attacks in RSA, it can give key compromise attacks. |
There was a problem hiding this comment.
Thanks, this is a good additional example. If you don't mind I'll work this into the text.
3 participants
Added suggestions and comments