Caution on tweaking in bip 327

[AdamISZ]

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/[email protected]/ ), 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 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).

[jonatack]

Changing these two words will make the CI happy.

Suggested change

Using 2 signing keys that are related with publically known tweaks (such as unhardened BIP32 derivation) is **not secure** in MuSig2 (see the attack described in [https://eprint.iacr.org/2025/692 the DahLIAS paper], Appendix A.2, which applies directly), in the specific sense that an attacker can complete the signing protocol after receiving only 1 partial signature, not 2. If a user were to spread signing keys across multiple hardware devices, but using the same wallet seed and different addresses from the same BIP32 branch, it would therefore not be secure. The same would be true for publically known multiplicative tweaks (K2 = c * K1), as well as additive tweaks (K2 = K1 + t*G).

Using 2 signing keys that are related with publicly known tweaks (such as unhardened BIP32 derivation) is **not secure** in MuSig2 (see the attack described in [https://eprint.iacr.org/2025/692 the DahLIAS paper], Appendix A.2, which applies directly), in the specific sense that an attacker can complete the signing protocol after receiving only 1 partial signature, not 2. If a user were to spread signing keys across multiple hardware devices, but using the same wallet seed and different addresses from the same BIP32 branch, it would therefore not be secure. The same would be true for publicly known multiplicative tweaks (K2 = c * K1), as well as additive tweaks (K2 = K1 + t*G).

[AdamISZ]

Thanks for taking the trouble @jonatack ! I will fix up the spellings (and I think a bunch of other not-quite-right stuff) if the content turns out to be useful.

[jonatack]

cc BIP authors @jonasnick @real-or-random @robot-dreams for feedback

[jonasnick]

Hi @AdamISZ, I do not quite understand this PR. The BIP does support unhardened tweaking of the input keys and as far as we know there's no vulnerability when using this BIP with tweaked input keys. That's because the BIP implements the countermeasure mentioned in the bitcoin-dev email: "fix is to make the secret key argument to the NonceGen algorithm mandatory", except that we've chosen to make the public key argument mandatory instead of the secret key.

[AdamISZ]

Hi @AdamISZ, I do not quite understand this PR. The BIP does support unhardened tweaking of the input keys and as far as we know there's no vulnerability when using this BIP with tweaked input keys. That's because the BIP implements the countermeasure mentioned in the bitcoin-dev email: "fix is to make the secret key argument to the NonceGen algorithm mandatory", except that we've chosen to make the public key argument mandatory instead of the secret key.

I also do not understand :) As per our earlier discussion, the scenario: victim has 2 signing devices with sk1 on device 1 and sk2 on device 2, where sk2 = sk1 + t, allows a completed MuSig2 aggregated signature if device 1 follows the steps: (1) share nonces R11, R12 and then after receiving R21, R22, shares partial sig s_1 = r_11 + b*r_12 + H(X~, R, m)a_1sk1 . Based on the attacker calculating R21 and R22 as multiples (a2/a1)*R11, (a2/a1)*R12. (I believe you'd earlier agreed that this does constitute an attack, though, as qualified at perhaps painful length in my description above, it's only an "attack" against a very unwise/stupid setup!).

How does the mitigation you mention affect this? That mitigation addresses the possibility that the honest signer might have pre-stored nonces and then the attacker can grind t values to use those nonces with different tweaked keys and parallel executions to do a Wagner attack. Here I'm just talking about using a key and a publicly known tweak at two indices (the whole thing about "outside the security definition" to have "two honest signer indices").

[jonasnick]

Ah, sorry, you're referring to this discussion on the ML from April which I had forgotten about. This is indeed not fixed by making the public key a mandatory argument to NonceGen. And on the ML I did say that it may make sense to mention this in the BIP. I was thrown off by

MuSig2 aggregated key using related (bip32 unhardened) individual keys in the list is very specifically insecure

because I don't think it's very specifically insecure. Security here is a matter of definitions. In the attack you outline, both signing devices have the same secret key, but with different tweaks. This is "stupid" as you say because it defeats the purpose of multisignatures, where a compromise of one of the keys does not allow forging signatures. Your attack allows to completing the signature to a Schnorr signature, even though only one device has signed. However, because a partial signature is needed, the owner of the secret key did authorize the message. We also do not specifically point out in the BIP that using the same key multiple times is insecure, because a partial signature for one of the keys is also a partial signature for the others. That's why the wording "is insecure" sounds a bit too strong to me.

Also, there's maybe a better citation than Appendix A.2 of the DahLIAS paper because it attacks a different scheme (MuSig2-IAS) and the attack is qualitatively different: it allows forging a signature for a different message, not the same one.

[AdamISZ]

We also do not specifically point out in the BIP that using the same key multiple times is insecure, because a partial signature for one of the keys is also a partial signature for the others. That's why the wording "is insecure" sounds a bit too strong to me.

Yes. It's clearly debatable whether this needs to be written somewhere, given the extensive caveats, and also the wording/presentation is debatable as you say; this PR was basically a first, or a zero-th draft.

I think what leads me to suggest adding a note is that it's a weakness, of some sort, that slips between the cracks; while you'd struggle to find any engineer that thought using related keys like this was a good idea, I'm not at all sure if you'd get an overwhelming number of them that knew that doing it is unsafe not only because getting access to one key gains control of both (or more) signers, but even when the secret key is not leaked (with an active attack).

Further, depending on the implementation, this is a deployment decision, i.e. it's not only a coder but more a user that can make this bad decision.

If I were trying to be imaginative and come up with some new scheme (using multisig) where this mattered, I would fail, because I can't imagine a scheme where someone might think it sensible to have two keys governed by the same secret key material, acting as additional authorization, when they could use two actually different keys instead. Perhaps I just lack imagination! So I did my best to outline in the above, a situation where, however badly considered, someone in user-land might actually do it.

Without any warning at any level of the "stack" (neither the original paper for the protocol, nor the BIP, nor any implementation of the BIP), it is conceivable that a user of an implementation might foolishly do it, thinking that "MuSig2 is designed to be safe in the presence of tweaks", which is a reasonable conclusion to draw from this BIP, at least absent a super-careful reading, and most specifically because there is an existing paragraph defining how (public) key checking in NonceGen defends against one real (if very corner-case-y) attack that uses tweaks.

Also, there's maybe a better citation than Appendix A.2 of the DahLIAS paper because it attacks a different scheme (MuSig2-IAS) and the attack is qualitatively different: it allows forging a signature for a different message, not the same one.

Yes. I wrote this because that's where I saw it; the attack mechanism is written clearly there. A different citation makes sense to avoid the confusion you mention.

[AdamISZ]

Updated in 5c060d4 ; now a briefer note in the main text, with a footnote explaining the background, which seems more appropriate. As well as formatting fixes. What remains: still referring to DahLIAS A2 but perhaps replace; also I think needs a changelog update.

Let me know if this format/phrasing seems reasonable or not.

[jonasnick]

not only because getting access to one key gains control of both (or more) signers, but even when the secret key is not leaked (with an active attack)

Yes, I agree that this is an important point and I agree that we should change the BIP to mention this. The main issues I have with this PR right now are:

1. Mentioning this problem only in the "Remarks on Security and Correctness" section. This section mainly gives background on the design and potential modifications, but is not expected to be read by read by implementers. If we want readers to understand this potential problem, we should mention it in the "Overview" section, where we note right at the top that "Implementers must make sure to understand this section thoroughly to avoid subtle mistakes that may lead to catastrophic failure.".
2. The sentence Using 2 signing keys that are related with publicly known tweaks (such as unhardened BIP32 derivation) is '''not secure''' may be confusing, because this scenario can be "secure", depending on what you mean by security.

I attempted to come up with a BIP change myself, but so far I haven't found a solution I'm happy with. Right now I think we should do the following

1. Mention in the Overview->Public Key Aggregation section that the individual keys can be derived via BIP 32 hardened and unhardedened derivation (at that point, the document has not introduced "tweaking" yet).
2. Mention in the same section, when talking about duplicate public keys, that if one signer produces a partial signature, it is possible to produce a partial signature for any duplicate public key, without knowledge of the secret key and combine it with the remaining signers' partial signatures to obtain a valid Schnorr signature (this distinguishes this attack from the already existing notion that "partial signatures are not signatures" in the Further Remarks section).
3. Mention that, similarly, if a signer produces a partial signature, it is possible to produce a partial signature for any public key in the key aggregation input that is derived from the same BIP 32 parent key, with knowledge of the "tweak" (BIP 32 does not use the term tweak) but without knowledge of the secret parent key. In BIP 32 unhardened derivation, the tweak may be public. Then, we could give an example for an attack (as in the current PR) and point out that this setup does not make mucn sense in the first place. Also, mention that this applies to other forms of tweaking as well and and refer to the "Tweaking with Individual Keys" section for more info.
4. In the "Tweaking with individual Keys" discuss in what way the BIP is secure vs. insecure with tweaked individual keys and refer to DahLIAS (or some other document) for the details of the attack.
5. Add Adam Gibson to the Acknowledgement section
6. Update the Changelog

[AdamISZ]

1. Mentioning this problem only in the "Remarks on Security and Correctness" section. This section mainly gives background on the design and potential modifications, but is not expected to be read by read by implementers. If we want readers to understand this potential problem, we should mention it in the "Overview" section, where we note right at the top that "Implementers must make sure to understand this section thoroughly to avoid subtle mistakes that may lead to catastrophic failure.".

That's a very good point. I settled on one specific location without thinking about it too much, but I agree this is not the right place. I was hoping to keep it to a very compact comment to avoid further bloat (especially since it's a weird sub-case rather than a normal security concern). But as per the following, it probably needs a little more, and in a different location.

2. Mention in the same section, when talking about duplicate public keys, that if one signer produces a partial signature, it is possible to produce a partial signature for any duplicate public key, without knowledge of the secret key and combine it with the remaining signers' partial signatures to obtain a valid Schnorr signature (this distinguishes this attack from the already existing notion that "partial signatures are not signatures" in the Further Remarks section).
3. Mention that, similarly, if a signer produces a partial signature, it is possible to produce a partial signature for any public key in the key aggregation input that is derived from the same BIP 32 parent key, with knowledge of the "tweak" (BIP 32 does not use the term tweak) but without knowledge of the secret parent key. In BIP 32 unhardened derivation, the tweak may be public. Then, we could give an example for an attack (as in the current PR) and point out that this setup does not make mucn sense in the first place. Also, mention that this applies to other forms of tweaking as well and and refer to the "Tweaking with Individual Keys" section for more info.

Ah. Yes that's more natural. The "two keys related by a public tweak" is closely connected with the simple "repeated key" case, so it fits there.

One thing that is currently tacit: I'm assuming you agree that the comment(s) mention(s) that multiplicative tweaks are vulnerable in the same way as additive?

I'll get back with an altered suggestion soonish, thanks.

Oh and btw:

The sentence Using 2 signing keys that are related with publicly known tweaks (such as unhardened BIP32 derivation) is '''not secure''' may be confusing, because this scenario can be "secure", depending on what you mean by security.

Right. I have tended to sit on one side of this, with the line of thinking: "if someone did this, they would do it because they saw the two authorizations as distinct, for example, they want to avoid malware address replacement attacks one one HW setup, and are not scared (for some reason) that key theft is possible)" (and to note: same logic is therefore applicable with repeated key, i.e. tweak 0) but I can't deny what you say: it's secure in the standard way of thinking that "if "I" authorize then there is not an attack on me" (current security games have one honest party and consider that sufficient).

So maybe the right way to write this patch is, as per your suggestion above "treat a public tweak as a delta to the repeated key case" and note the difference (there is a difference, but it isn't much).