The BIP is quite difficult to parse in terms of understanding the functionality and safety of tweaking keys.
In particular, while it is a terrible idea for more than one reason, constructing a MuSig2 aggregated key using related (bip32 unhardened) individual keys in the list is very specifically insecure, but that is not noted.
It’s admittedly debatable whether you ever have to specify that a certain kind of stupid behaviour is to be warned against, but my justification is:
-
The BIP is very explicitly “supporting tweaking” right from the Abstract. It isn’t immediately clear that this means tweaking the ouput, not the input. Perhaps a minor note early on would help with that.
-
Pre- this patch, in the section I’m editing, the document again explicitly says it supports tweaking, and this time, in relation to the input keys. It then goes on to explain the background of the attack outlined on the mailing list (I updated to a gnusha link: https://gnusha.org/pi/bitcoindev/576db60c-b05b-5b9a-75e5-9610f3e04eda@gmail.com/ ), which is much more “in scope” in the sense that the honest signer behaviour isn’t stupid, but at the same time, the conditions of that attack are quite obscure.
-
While the behaviour is stupid, it’s not inconceivable, and it sits within perhaps the most likely/common usage pattern of MuSig2: multisig for better cold storage/savings security. Multiple keys controlled by the same signer, using multiple hardware devices for redundant security. As noted by Jonas Nick in an earlier email convo we had, there is at least one reason such stupid behaviour might be considered: less backup (and/or laziness). I admit that a large majority would have the common sense to not reuse the same wallet seed across devices, but in case anyone did it, they are exposed in a specific way that is very unobvious.
-
To generalize the above, for me the BIP is not sufficiently explicit that the design of the MuSig2 algorithm does not address the possibility of related input keys at all (and it would be easy as an engineer consumer to assume that related keys would be safe, if they didn’t look at the mathematical formulas too much).
If you want a concrete description of the attack, here you go (see Appendix A.2 of DahLIAS for what I mean by “multipliers:”):
2 devices set up with one secret key each, where the keys are on the same branch so that sk1 = sk2 + t for “public” t (handwave).
The network is compromised by the attacker. It exchanges messages with device 1 (sk1); receives nonces, maliciously calculates the response nonces (with the multipliers), receives a partial sig for sk1 and can complete the signing protocol just from knowing t.
The higher-level idea here is (I’m cribbing from an earlier email I wrote):
… which I think nicely illustrates something that occurred to me earlier: there’s a question of “what is authorization?” being raised here. In a single key signature, there is a single authorizing event, so we never worry too much about the “semantics” of the action of signing. It’s one action, and it’s all or nothing: you authorize, or you don’t.
In multi-signing it’s not atomic. The semantics of individual signing events are something decided on by the operator(s) of the protocol. I might want to say “I authorize if and only if 3 different hardware devices sign” (or 3 people or whatever). How does the security definition represent this? I believe the rationale for applying EUF-CMA as in the paper is “we take a maximally pessimistic approach and assume that all except honest are the adversary, then we demand the adversary produce a signature without authorizing events from the honest signer” on the basis that, if the honest signer did authorize, then there is no security failure (the honest signer wanted it!) - but that’s exactly the point I’m questioning.
So it’s back to the slightly confusion position of “that this is possible is worrying, but all the obvious ways of exploiting it as a weakness reduce to an already fundamentally insecure multisig setup (using calculable tweaks of existing keys), and the base security model does not include this” (“capture”, perhaps).
Whimsically I wonder if this can be seen as analogous to EUF style security vs SUF style security: for most purposes you don’t need strong unforgeability but it can cause implementation headaches if you don’t have it (MtGox, hehe).
