Add description of MuSig signing to musig-spec.md

[jonasnick]

Will wait before adding tweaking until #151 is merged.

[robot-dreams]

Looking great so far! Aside from inline comments:

• For each of the various functions that take a list of input public keys, is there a precondition on the input public keys being already sorted, or is the function expected to sort the keys itself, or neither?

• There are a few places where you're using lift_x(int(...)) where the input is a 33-byte compressed representation, rather than a 32-byte x-only representation. Is it necessary to define a new helper to handle this case?

[robot-dreams]

I think your argument makes sense, but is it also worth adding something like "the attacker's nonce pairs aren't used anywhere else, except to generate the final nonce"?

For example, you could imagine that if H_sig depended not just on the final nonce, but also on the attacker's choice of pre-nonces, then the modified scheme would be broken, because you could get two partial signatures with the same final nonce R but two different values of c.

[jonasnick]

I don't understand. You're saying that the attacker can send R_neg = - R_others and R_neg + G and both will result in the same final nonce R. If you get two partial sigs with the same R but two different values of c, then the secnonce has been reused. The attacker can also get same R different c by choosing a different message if the secnonce is reused.

[robot-dreams]

Oops, what I said before was nonsense. I forgot that the adversary also needs the private pre-nonces, haha.

Is it correct if an adversary A can win the EUF-CMA game against the modified scheme (call it MuSig2'), then A can be used directly to also win the EUF-CMA game against MuSig2*?

I'm thinking every query that A makes against a MuSig2' challenger (H_agg, H_non, H_sig, Sign, Sign') is also a valid query against a MuSig2* challenger (I assume this is what you meant by "only restricts the abilities of the attacker"), and a valid forgery (L, m, (R, s)) against MuSig2' is also a valid forgery against MuSig2*; thus the "reduction" is completely trivial.

[jonasnick]

Hm, I had to think about this quite a bit again which is an indication that we should expand on this argument a bit. Well, now we have the space for it.

then A can be used directly to also win the EUF-CMA game against MuSig2*?

I don't think so. If A sends a Sign' query with aggnonce[0] = infinity, it expects a partial signature using aggnonce[0] = G. Therefore, a reduction would need to add G to A's query if it is infinity.

a valid forgery (L, m, (R, s)) against MuSig2' is also a valid forgery against MuSig2*

What confused me a bit is that R = infinity is allowed in principle in MuSig2*. The scheme we're comparing this to is where R = infinity in a forgery is disallowed already (which is what BIP340 also implements).

[robot-dreams]

Ah, I think I see what you're saying.

I was previously consideringNonceAgg as being done by the adversary, including the part where it possibly replaces infinity with the generator (because NonceAgg only depends on public data). By the way, in this case, I think if Sign' for MuSig2' receives infinity as one of the aggnonces, the Sign' query should just fail.

But if replacing infinity with the generator is done inside Sign', by the MuSig2' challenger, then I agree with you that the reduction needs to replace infinity with the generator before passing the query onto the MuSig2* challenger.

[robot-dreams]

Here's a suggestion for an alternate way to argue about the security of the modification. I'm not 100% confident in it but if this general idea works I think it might be easier to understand:

Note that NonceAgg (both the original and modified version) only depends on publicly available data (the set of public pre-nonces from every signer). Thus in the context of the signature security game (EUF-CMA), we can consider NonceAgg to be performed by the adversary (rather than the challenger) without loss of generality.

This modification changes neither the behavior of the EUF-CMA challenger nor the condition required to win the security game (the adversary still has to output a valid forgery according to the unmodified MuSig2* scheme). Since we've already proved that MuSig2* is secure against an arbitrary adversary, we can conclude that the modified scheme is still secure.

[jonasnick]

But if replacing infinity with the generator is done inside Sign', by the MuSig2' challenger, then I agree with you

You're right, what I said is nonsense. Aggregation happens outside of Sign' exactly because we don't want to trust aggregation.

The sentence "it only restricts the abilities of the attacker" is wrong, because the abilities of the attacker are exactly the same (arbitrary NonceAgg). I pushed your suggestion (after minor modifications).

CC @real-or-random

[real-or-random]

I was also confused first but I think now the argument makes sense. Wording can still be improved. Right now it sounds like we're coming up with this argument here in the spec but the EUF-CMA game in the paper already lets the adversary perform NonceAgg (=SignAgg in the paper).

So I believe a formal argument is as simple as this.

Let MuSig2* be the scheme from the paper, let MuSig2† be MuSig2* with the modification that the scheme simply aborts if one of the aggregate nonces is infinity, and let MuSig2†† be the scheme in the spec. (Note that MuSig2†† also aborts if the one of the aggregate nonces is infinity because then parsing fails.)

MuSig2* is EUF-CMA by the theorem in the paper. Since Sign† only adds aborts to Sign*, and the adversary can simulate internally whether Sign† will hit those aborts (by checking whether one of the aggregate nonces is infinity), MuSig2† is EUF-CMA. Since MuSig2† and MuSig2†† differ only in NonceAgg, the EUF-CMA games of MuSig2† and MuSig2†† are identical. Thus MuSig2†† is EUF-CMA.

(This could also be written nicely in game hopping style.)

[robot-dreams]

OK, I think I'm following—my problem with my informal argument above is that it doesn't account for the extra "abort" possibility (it used without proof the fact that MuSig2† is secure). Here's my understanding of your formal argument, is this correct?

• Suppose we have adversary A†† that wins MuSig2†† game[1]; here's how we build A†:

  • Use A†† directly, since MuSig2† and MuSig2†† are the same game

• Suppose we have adversary A† that wins MuSig2† game; here's how we build A*:

  • Start with transparent wrapper around A†
  • Whenever A† makes call to Sign†, first check public nonces
    • If either of them is infinity, return "abort" to A†
    • Otherwise, forward call to Sign* and return result to A†
  • Wrapper simulates Sign† perfectly to A†, and everything else is unchanged
  • The forgery that A† outputs wins MuSig2† (of course) but it also wins MuSig2*

Thus if we have adversary A†† that wins MuSig2†† game, then we could build A* that wins MuSig2* game. From the paper, we can't have adversary A* that wins MuSig2* game. So taking the contrapositive, we can't have adversary A†† that wins MuSig2†† game. So the scheme in the spec is secure.

[1] I mean "wins ... game with non-negligible probability" everywhere, but I'll leave that out to keep it shorter.

[real-or-random]

Yes, exactly correct! So your wrapper around A† is the formal implementation of my sentence "the adversary can simulate internally whether Sign† will hit those aborts (by checking whether one of the aggregate nonces is infinity)".

I think the "abort" thing is a very minor detail here -- but I believe it's necessary in a fully rigorous proof: by observing aborts, the adversary could learn new information (say Sign† aborts iff the last bit of the secret key is 1).

But since the aborts in fact depend only on publicly available information, this is not the case here. And your reduction formalizes this intuition: whatever can be learned from a Sign† oracle (which can abort) can also be learned from a Sign* oracle (which does not abort), simply by determining locally whether Sign† would abort.

This also means that the current text is slightly wrong, when it says "This modification changes neither the behavior of the EUF-CMA challenger". The modification does change the behavior of the EUF-CMA challenger, namely by introducing aborts -- but it does so only in a way that anyhow can be simulated by the adversary.

[jonasnick]

@robot-dreams

For each of the various functions that take a list of input public keys, is there a precondition on the input public keys being already sorted, or is the function expected to sort the keys itself, or neither?

Neither. Added a note that the output of KeyAgg is dependent on the order of the inputs. So either implementors of the spec make sure that that all signers get the same order of pubkeys or they sort them according to the spec (see discussion here #120).

Is it necessary to define a new helper to handle this case?

Oops, added point and pointc function.

[brandonblack]

Great to see this in detail and with clear definitions for inputs!

[brandonblack]

Suggested change

	** If ''pk<sub>j</sub> &ne; pk<sub>1</sub>'':
	** If ''pk<sub>j</sub> &eq; pk<sub>2</sub>'':

[jonasnick]

That's not equivalent if pk1 = pk2. We really want the "second pubkey" in the sense that it's unequal from the first.

[robot-dreams]

I did a second review pass by just trying to implement the spec directly and seeing if any issues came up.

Aside from the inline comments below, the spec was enough to produce the expected test vectors for KeyAgg and Sign :)

[robot-dreams]

Where does pubnonce<sub>1..u</sub> come from, since this isn't an input to Sign?

[jonasnick]

I added a PartialSigVerifyInternal function that takes the aggregate nonce.
I didn't want to replace the pubnonces argument of PartialSigVerify with aggnonce because that would wrongly indicate that verifying makes sense with untrusted nonce aggregation

[robot-dreams]

OK, sounds good for now, but I do want to think about this more if you add adaptors to the spec (since the implementation has comments that it's much more important to call PartialSigVerify in that case)

[roconnor-blockstream]

To be used with taproot, signing also needs a tweak parameter. I don't know if this needs to be passed into the nonce stuff.

[jonasnick]

Yes, see the PR description:

Will wait before adding tweaking until #151 is merged.

The implementation already has x-only tweaking and #151 adds "ordinary" tweaking.

[jonasnick]

@robot-dreams

Aside from the inline comments below, the spec was enough to produce the expected test vectors for KeyAgg and Sign :)

Excellent, that's great to hear. Thank you for the review!

[jonasnick]

Rebased

[robot-dreams]

ACK 623f3cb 🚀

[jonasnick]

Squashed fixups

[jonasnick]

I'm tending towards changing the serialization of the nonce pair from compressed(R1) || compressed(R2) (66 bytes) to parity(R1) | parity(R2) << 1 || xonly(R1) || xonly(R2) (65 bytes).

[brandonblack]

parity(R1) | parity(R2) << 1? (| instead of &)

Although I'm having a hard time thinking of a case where this 1 byte matters, given that the partial nonces never appear in the blockchain.

[jonasnick]

Eh sure, edited. OTOH there's no reason to add a useless byte.

[jonasnick]

Squashed fixup & rebased

[robot-dreams]

ACK 69b392f based on:

• Add description of MuSig signing to musig-spec.md #157 (comment)
• 623f3cb -> 703f741 was a squash
• Inspected output of "git range-diff a5b5909 703f741 69b392f"

[real-or-random]

ACK 69b392f I haven't looked at every detail but it's certainly ready to be merged as draft spec

I think we should move this to a separate repo (fork of bips repo) soon.