Update bip-0327.mediawiki

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:

1. 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.

2. 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.

3. 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.

4. 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](https://eprint.iacr.org/2025/692) 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).

Author: AdamISZ

bip-0327.mediawiki

@@ -533,8 +533,10 @@ The reference implementation is for demonstration purposes only and not to be us
 
 === Signing with Tweaked Individual Keys ===
 
-The scheme in this proposal has been designed to be secure
-even if signers tweak their individual secret keys with tweaks known to the adversary (e.g., as in BIP32 unhardened derivation)
+Using 2 signing keys that are related with publicly known tweaks (such as unhardened BIP32 derivation) is '''not secure''' in MuSig2, even aside from the obvious reason (that access to one key, implies access to the other, so the main security guarantee of multi-signing is lost). <ref> See the attack described in [https://eprint.iacr.org/2025/692 the DahLIAS paper], Appendix A.2. An attacker compromising only network connections, and not secret keys, can complete a MuSig2 session using two related keys, after just seeing one signature from the honest counterparty, i.e. they do not need to steal a key. Obviously this is not an attack of the normal type, and is thus not covered, nor discussed in MuSig2 itself, but in case of designing a deployment or protocol using such a construction for any reason, note that it fails to provide security against such attacks. This same comment applies to a multiplicative tweak like ''K<sub>2</sub> = c * K<sub>1</sub>'', not only to additive tweaks like ''K<sub>2</sub> = K<sub>1</sub> + t*G''.</ref>
+
+However, the scheme in this proposal has been designed to be secure
+even if signers tweak their ''individual'' secret keys with tweaks known to the adversary (e.g., as in BIP32 unhardened derivation)
 before providing the corresponding individual public keys as input to key aggregation.
 In particular, the scheme as specified above requires each signer to provide a final individual public key ''pk'' already to ''NonceGen'',
 which writes it into the ''secnonce'' array
@@ -549,7 +551,7 @@ which have been obtained via tweaking another secret key with tweaks known to th
 then the adversary could, after having seen the ''pubnonce'',
 influence whether ''sk<sub>1</sub>'' or ''sk<sub>2</sub>'' is provided to ''Sign''.
 This degree of freedom may allow the adversary to perform a generalized birthday attack and thereby forge a signature
-(see [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021000.html bitcoin-dev mailing list post] and [https://github.com/jonasnick/musig2-tweaking writeup] for details).
+(see [https://gnusha.org/pi/bitcoindev/576db60c-b05b-5b9a-75e5-9610f3e04eda@gmail.com/ bitcoin-dev mailing list post] and [https://github.com/jonasnick/musig2-tweaking writeup] for details).
 
 Checking ''pk'' against ''IndividualPubkey(sk)'' is a simple way to ensure
 that the secret key provided to ''Sign'' is fully determined already when ''NonceGen'' is invoked.