Thanks for bringing this up. It's an interesting question and it made us realize that we should clarify this section of the paper, as there are indeed some subtleties here that are currently unmentioned.
> I don't understand why this same attack cannot be applied to MuSig2 itself? There are nuances, but I think it's fair to say that the same attack cannot be applied to MuSig2 itself. During the attack, the adversary requests a partial signature for public key X and message m from the honest signer. Using this, the adversary is able to create a partial signature for public key X' = TweakPK(X, t), where t is some tweak chosen by the adversary, and message m'. When applying the attack to MuSig2, we have that m' = m, and when applying it to MuSig2-IAS, we may have m != m'. So, using the attack, the adversary is able to produce a signature sigma_1 for MuSig2 and sigma_2 for MuSig2-IAS such that - MuSig2.Verify(KeyAgg(X, X'), m, sigma_1) = 1, and - MuSig2-IAS.Verify((X, m), (X', m'), sigma_2) = 1. sigma_2 is clearly a forgery under the EUF-CMA-TK security model defined in the DahLIAS paper because it is a signature for a message m' that the honest signer hasn't signed. In contrast, sigma_1 only covers the message that the honest signer actually signed. Whether sigma_1 counts as a forgery depends on the abstract security notion that you consider for multisignature tweaking. We didn't provide such a model in the MuSig2 paper and I am not aware of a standard one. It would be easy to design a security model where sigma_1 constitutes a forgery and one where it doesn't. More importantly, could this be a problem for MuSig2 in practice? I can only come up with contrived scenarios, but it may still be worth mentioning in the BIP, for example. -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/2ede88e8-2570-442f-a073-730f7de70eca%40gmail.com.
