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]
