Address AdamISZ's feedback regarding duplicate public keys #25
Conversation
|
I still feel like this wording does not convey to the reader the fact that not every one of an attacker's indices can be identified in case of receiving an incorrect contribution. There's considerable finesse here as per our discussion on-list, i.e. to what extent does it matter, but clearly we're trying to be precise, maybe just something like this?:
But obviously your call. |
|
I'll wait for the other authors to weigh in. |
|
I think the example of forgeability of partial sigs is somewhat besides the point. When it comes to disruption and the ability to identify malicious signers ("identifiable aborts"), this property holds in MuSig2 even for maliciously created keys, i.e., whether the attacker knows a secret key or not is relevant for unforgeability but not for identifiable aborts. (See also the ROAST paper, where we make this formal for FROST; the exact same argument applies to MuSig2.) So in the example where the attacker controls signers 4 and 5, and doesn't have the secret key of 4 but still manages to produce a contribution that passes partial verification, you could say that 4 behaves honestly with respect to identifiable aborts. It doesn't really matter that the attacker doesn't know the secret key. (The attacker could equivalently also know it and not use it.) Similarly, the attacker could make signer 4 always use the same two EC points in the nonce, or always choose the secret key to be the constant 42. Such a signer is clearly not honest in the sense that it doesn't adhere to the protocol but we simply don't care when it comes to identifiable aborts. So I believe one could argue that the protocol really identifies all signers which behave disruptively in a particular session. Of course, we can't identify all signers controlled by the attacker, because they could behave honestly in this particular session (and possibly be disruptive only in future sessions, if such sessions exist). But I totally see that this is subtle and debatable, and we shouldn't go into these details in the BIP. In the end, the protocol guarantees the following property, which is all that users of the protocol need to know, and so this is all we need to say in the BIP: If the signing session fails to output a valid signature, then each honest signer will identify exactly one disruptive signer, who sent incorrect contributions in the session, and return the index of the disruptive signer. And I believe this is in line with @AdamISZ's suggestions, (I hope) I'm just rephrasing. We should also mention this very useful property: (We can replace "disruptive" by "malicious", open to bikeshedding here.) |
|
Thanks @real-or-random that's a really interesting way of looking at it. On reflection from that, I think I can see that ultimately what I'm worried about is something that's cautioned already, expicitly, in the document, namely that partial signatures are not proofs of knowledge. As per here:
Anybody sufficiently thoughtful to 'do this right' will presumably, in any meta-protocol, take account of this fact. It could be a "gotcha" in some use case, but this BIP can't really do more than inform of that fact.
This looks good to me but: I don't get why you say 'exactly one', can't more than one signer output garbage/not follow the rules? |
Ok yes, I said "exactly one" because our algorithms currently output only one. (see also #9 ). But on a second thought, that's not really true... I mean sure, for example |
|
Added @real-or-random's suggestion (slightly rephrased, since PartialSigVerify doesn't return the index of the signer, that's something the application needs to handle) and moved this part to the "Identifying Disruptive Signers" section. |
jonasnick
changed the title
|
ACK 3aabe68 |
No description provided.