> > RSA and ECDSA do not have domain separation at all. Indeed, but we were discussing ML-DSA, not RSA or ECDSA.
I was thinking the following interactive protocol: Ah, I see. Yes, that two-trip protocol seems like it would work. Unfortunately a two-trip protocol is beyond the scope we have in mind at the moment, and I don't think this can be done in one trip. Hm... what if digester chooses a random r and lets R = [r]B + A? Then signer instead computes S = ((r + s) + H(R || A || phm) * s) mod L. Nope, breaks if digester maliciously chooses r = 0, then solving for s gives S * inv(H(R || A || phm)) * inv(inv(H(R || A || phm)) + 1) = s. Anyway, yeah, I think we'll just not define two-party alg identifiers for the "pure" variants of EdDSA or ML-DSA. Emil Lundberg Staff Engineer | Yubico <http://www.yubico.com/> Den fre 4 okt. 2024 kl 13:53 skrev Ilari Liusvaara <[email protected] >: > On Fri, Oct 04, 2024 at 11:46:15AM +0200, Emil Lundberg wrote: > > 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. > > RSA and ECDSA do not have domain separation at all. > > And I don't see a way to control domain separation yet have > compatible signatures. > > > > 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: > > I was thinking the following interactive protocol: > > 1) Digester requests R and A. > 2) Signer generates random r. > 3) Signer computes R=r*G and A=a*G (a is derived from private key). > 4) Signer sends R and A to digester. > 5) Digester computes h=H(R,A,M). > 6) Digester sends h to signer. > 7) Signer compte s = r + h * a (mod l). > 8) Signer sends s to digester. > 9) Digester takes (R,s) as signature. > > Now, with caveats that: > > - Step 7 never occurs multiple times per step 2. > - The r generated in step 2 is independent and uniformly random. > > Digester can not recover the private scalar. > > > > 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 > > The "playing with fire" was about how difficlt it is to implement. > > > > > -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]
