ed25519.cosi: Public key cancellation

[prusnak]

Draft of paper "Schnorr Multisignatures for Bitcoin" paper (chapter 2.3) by Pieter Wuille suggest the following change to avoid public key cancellation.

We change the computation of s_i in the original multisigning scheme

from

s_i ← k_i − x_ie

to

s_i ← k_i − H(C || P_i) x_ie

and the resulting combined public key

from

P = sum_1..m[ P_i ]

to

P = sum_1..m[ H(C || P_i) P_i ]

where C is a key set commitment C = H(P₁ || ... || P_n) and H is a random oracle (i.e. hash function).

I suggest reading the whole chapter 2.3 for more thorough explanation.

[bford]

Thanks Pavol. We're completely open to potential refinements like this to increase robustness to related-key (or key-cancellation) attacks. I seem to recall that refinements like these were discussed on the CFRG list back in the work leading up to RFC 8032, but weren't adopted in that context for reasons I don't remember well - perhaps simply because the focus then was on individual rather than collective signatures. Can anyone else remember exactly when that discussion occurred or find the relevant messages in the CFRG list archive?

At any rate, our Internet-Draft on collective signing is intended to be just a first draft, not by any means a final specification. Our immediate goal is to get a critical mass of support within CFRG for standardizing collective signing as a working group item. Once we get to that point, then we can begin the process of (collectively) figuring out exactly what that signing scheme should look like, including which particular hardening refinements such as this it should include. So what would be ideal at the moment is if you could post to the CFRG mailing list an E-mail stating (a) that you support the CFRG working on specifying some kind of collective signing scheme as a working group item, and (b) a list of issues or changes such as the above that you'd like to see considered in the context of that work. Thanks again!