Thank you Ilari - For ML-DSA, it is possible to calculate the internal hash (mu; 64 bytes) > from the public key and message.
I agree this is possible, with the caveat that it moves control of the domain separation tags away from the "signer" (the one holding the private key) to the "digester" (the one computing the initial digest), because the domain separation tags are applied before hashing to μ in step 6. In our use case the "digester" is somewhat trusted, but not trusted with access to the private key, so prefer to give it as little influence over the signing procedure as possible. Since the same spec already defines HashML-DSA, I think it's safer to restrict ourselves to that since that keeps the "signer" in control of the domain separation tags. For PureEdDSA (and SLH-DSA), to get two-party signing with O(1) > communication, interactive (two-round) protocol is required. This is > possible exploiting the fact that verifiers can not detect if the > first message-dependent value has been replaced by random value. > However, this is playing with fire (the protocol must never fork > and random numbers have to be absolutely perfect). Hm, interesting. I took another look at the EdDSA algorithm <https://www.rfc-editor.org/rfc/rfc8032#section-3.2> and I agree that pre-hashing PureEdDSA would indeed be possible like you describe, but with the *enormous* caveat that it gives the "digester" access to the private scalar: The EdDSA public-private key pair is (A, k): h_bits = H(k) s = bits_to_scalar(h_bits) A = [s]B Now consider a two-party signing protocol like this: Digester computes: r = H(h_bits || M) phm = PH(M) Digester transmits r, phm to Signer. Signer computes: R = [r]B S = (r + H(R || A || phm) * s) mod L Assume the "signer" returns the signature to the "digester" which relays it to the intended recipient. We can therefore assume the "digester" knows the public values A, R and S. The "digester" can now recover the private scalar: S - r = H(R || A || phm) * s (S - r) * ModInv(H(R || A || phm)) = s Thus the "digester" now knows the private scalar s and can use it to forge signatures. So yes, I agree this is "playing with fire" and would not work with our intended use case where the "digester" is not supposed to know the signing private key. Therefore the mockup document includes examples for Ed25519ph and HashML-DSA, but not "pure" Ed25519 or ML-DSA: https://yubico.github.io/arkg-rfc/cose-two-party-sign-algs/draft-bradleylundberg-cfrg-arkg.html Cheers, Emil Lundberg Staff Engineer | Yubico <http://www.yubico.com/> Den tors 3 okt. 2024 kl 22:50 skrev Ilari Liusvaara < [email protected]>: > On Thu, Oct 03, 2024 at 08:00:16PM +0200, Emil Lundberg wrote: > > > > If you don't want domain separation, then you simply need to identify > > > registered algorithms, > > > > > > For the keys and the resulting cryptograms, yes. But that's not what my > > question was about. > > > > [...] where you can do the pre hash part separate from the signing part. > > > > [...] > > > > [...] but be careful, this does not generalize to other COSE digital > > > signature schemes, like Ed25519 / EdDSA. > > > > > > This is what I'm asking about - or, more precisely, how to communicate > > where the separation happens between "pre hash part" and "signing part". > > Like you point out, there's no way to describe that generically, > especially > > since some algorithms like PureEdDSA and ML-DSA *can't* be separated like > > that. > > For ML-DSA, it is possible to calculate the internal hash (mu; 64 bytes) > from the public key and message. > > For PureEdDSA (and SLH-DSA), to get two-party signing with O(1) > communication, interactive (two-round) protocol is required. This is > possible exploiting the fact that verifiers can not detect if the > first message-dependent value has been replaced by random value. > However, this is playing with fire (the protocol must never fork > and random numbers have to be absolutely perfect). > > > > > -Ilari > > _______________________________________________ > COSE mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
