The Musig2 BIP says that signing two distinct messages with the same secnonce exposes your private key. While I know we must absolutely not reuse secnonces, I wanted to check how the private key extraction worked and the difference with a standard schnorr sig.
And I couldn’t figure it out! It seems to me that an attacker would need three partial sigs for distinct messages using the same secnonce, two doesn’t seem to be enough?
Here is a simplified write-up of the equations, with a slightly different naming than the BIP to focus only on the important parts:
Alice has public key Pa = ka*G
Bob has public key Pb = kb*G
Q is the aggregated public key
R is the public aggregated nonce
b = H("noncecoef" || R || Q || m)
e = H("challenge" || R || Q || m)
=> implies that an attacker cannot choose (rb1', rb2') to influence b' thanks to H's preimage resistance
First signature for message m1:
sa1 = ra1 + b1*ra2 + e1*a*ka
sb1 = rb1 + b1*rb2 + e1*a*kb
Second signature for message m2 where Alice reuses ra1 and ra2:
sa2 = ra1 + b2*ra2 + e2*a*ka
sb2 = rb1' + b2*rb2' + e2*a*kb
The attacker ends up with:
sa2 - sa1 = (b2 - b1)*ra2 + a*(e2 - e1)*ka
The attacker ends up with one equation but two unknowns (ra2 and ka), so it’s not sufficient to extract ka? It needs a third signature to obtain a second equation and solve for both ra2 and ka? What am I missing?
I don’t think you’re missing anything; though perhaps some wagner-ish approach could also cause you to reveal your secret key if you sign many times while only using any single nonce pair twice. With musig2 you effectively have two nonces (ra_1, ra_2), so giving you three unknowns (ra_1, ra_2, ka) so needing three equations (signatures) to solve for three unknowns seems sensible.
I believe you are correct for musig2. But the older MuSig1 has no nonce coefficient b, and so reusing a nonce even once will expose your signing key the same way that reusing a Schnorr signing nonce will.
If you have three partial signatures under the same nonce, it is possible to extract the secret key, although the algebra involved is a bit overzealous.
Given:
s_1 = r_1 + r_2 b_1 + e_1 k a
s_2 = r_1 + r_2 b_2 + e_2 k a
s_3 = r_1 + r_2 b_3 + e_3 k a
You can solve for k as:
k = \frac{(s_3-s_1)(b_2-b_1) - (s_2-s_1)(b_3-b_1)}{a \left( (e_3-e_1)(b_2-b_1) + (e_1-e_2)(b_3-b_1) \right)}
Also worth noting: Reusing nonces in musig is bad even if you are signing the same message, because other signers can change their nonces and thus change the aggregated nonce, which changes e the same way that changing the message would.
Indeed, you can’t extract the signing key from just two signatures with the same nonce. You’ll get two equations from the two signatures, but you have three unknowns.
But what’s also true is that security under concurrent sessions breaks down again. Assume the attacker can ask the honest signer for many concurrent signing sessions with limited reuse of nonces, i.e., each nonce (pair) may be used at most in two signing sessions. Then a forgery is possible.
The attack is very similar to the attack on “InsecureMuSig” descriped in the MuSig2 paper (pages 5 and 6). It just gets more hairy because we need to correct for b factors everywhere. Following the notation in the paper, the attacker opens
\newcommand{\si}{k}
\newcommand{\smax}{k_{\mathrm{max}}}
\newcommand{\Hsig}{\mathsf{H}_{\mathrm{sig}}}
\newcommand{\tX}{\widetilde{X}}
\smax session pairs, where the user reuses the same nonce pair in the two sessions belonging to a session pair. That is, the user (signer index 1), responds with \smax nonce pairs (R_{1,1}^{(\si)}, R_{1,2}^{(\si)}). The adversary (signer index 2) chooses a targer message m^*, computes
R^* = \prod_{k=1}^{\smax} R_{1,1}^{(\si)}
and uses Wagner’s algorithm or the recently discovered and much faster BLLOR algorithm to find their nonce pairs (R_{2,1}^{(k)}, R_{2,2}^{(k)}) for each session pair such that
exactly as in the paper.
The attack then proceeds as described in the paper.
edit: If you see rendering errors in the equations, try to reload the page. I think Discourse here uses some optimizations where it loads the equations in the wrong order, and then they won’t work.
Are you referring to the following statement from BIP327?
The Sign algorithm must not be executed twice with the same secnonce. Otherwise, it is possible to extract the secret signing key from the two partial signatures output by the two executions of Sign.’
Hm, yes, we should probably change the wording here.