frost/secp256k1-zkp
3
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity

musig: replace MuSig(1) with MuSig2

Browse Source
This commit is contained in:
Jonas Nick
2021-05-05 15:45:31 +00:00
parent e290c0f835
commit 22c88815c7
15 changed files with 2886 additions and 2256 deletions
Download Patch File Download Diff File Expand all files Collapse all files

221
src/modules/musig/musig.md
View File

@@ -1,198 +1,63 @@
MuSig - Rogue-Key-Resistant Multisignatures Module
Notes on the musig module API
===========================
This module implements the MuSig [1] multisignature scheme. The majority of
the module is an API designed to be used by signing or auditing participants
in a multisignature scheme. This involves a somewhat complex state machine
and significant effort has been taken to prevent accidental misuse of the
API in ways that could lead to accidental signatures or loss of key material.
The following sections contain additional notes on the API of the musig module (`include/secp256k1_musig.h`).
A usage example can be found in `examples/musig.c`.
The resulting signatures are valid Schnorr signatures as described in [2].
# API misuse
# Theory
The musig API is designed to be as misuse resistant as possible.
However, the MuSig protocol has some additional failure modes (mainly due to interactivity) that do not appear in single-signing.
While the results can be catastrophic (e.g. leaking of the secret key), it is unfortunately not possible for the musig implementation to rule out all such failure modes.
In MuSig all signers contribute key material to a single signing key,
using the equation
Therefore, users of the musig module must take great care to make sure of the following:
P = sum_i µ_i * P_i
1. A unique nonce per signing session is generated in `secp256k1_musig_nonce_gen`.
See the corresponding comment in `include/secp256k1_musig.h` for how to ensure that.
2. The `secp256k1_musig_secnonce` structure is never copied or serialized.
See also the comment on `secp256k1_musig_secnonce` in `include/secp256k1_musig.h`.
3. Opaque data structures are never written to or read from directly.
Instead, only the provided accessor functions are used.
4. If adaptor signatures are used, all partial signatures are verified.
where `P_i` is the public key of the `i`th signer and `µ_i` is a so-called
_MuSig coefficient_ computed according to the following equation
# Key Aggregation and (Taproot) Tweaking
L = H(P_1 || P_2 || ... || P_n)
µ_i = H(L || i)
Given a set of public keys, the aggregate public key is computed with `secp256k1_musig_pubkey_agg`.
A (Taproot) tweak can be added to the resulting public key with `secp256k1_xonly_pubkey_tweak_add`.
where H is a hash function modelled as a random oracle.
# Signing
To produce a multisignature `(s, R)` on a message `m` using verification key
`P`, signers act as follows:
This is covered by `examples/musig.c`.
Essentially, the protocol proceeds in the following steps:
1. Each computes a nonce, or ephemeral keypair, `(k_i, R_i)`. Every signer
communicates `H(R_i)` to every participant (both signers and auditors).
2. Upon receipt of every `H(R_i)`, each signer communicates `R_i` to every
participant. The recipients check that each `R_i` is consistent with the
previously-communicated hash.
3. Each signer computes a combined nonce
`R = sum_i R_i`
and shared challenge
`e = H(R || P || m)`
and partial signature
`s_i = k_i + µ_i*x_i*e`
where `x_i` is the secret key corresponding to `P_i`.
1. Generate a keypair with `secp256k1_keypair_create` and obtain the xonly public key with `secp256k1_keypair_xonly_pub`.
2. Call `secp256k1_musig_pubkey_agg` with the xonly pubkeys of all participants.
3. Optionally add a (Taproot) tweak with `secp256k1_musig_pubkey_tweak_add`.
4. Generate a pair of secret and public nonce with `secp256k1_musig_nonce_gen` and send the public nonce to the other signers.
5. Someone (not necessarily the signer) aggregates the public nonce with `secp256k1_musig_nonce_agg` and sends it to the signers.
6. Process the aggregate nonce with `secp256k1_musig_nonce_process`.
7. Create a partial signature with `secp256k1_musig_partial_sign`.
8. Verify the partial signatures (optional in some scenarios) with `secp256k1_musig_partial_sig_verify`.
9. Someone (not necessarily the signer) obtains all partial signatures and aggregates them into the final Schnorr signature using `secp256k1_musig_partial_sig_agg`.
The complete signature is then the `(s, R)` where `s = sum_i s_i` and `R = sum_i R_i`.
The aggregate signature can be verified with `secp256k1_schnorrsig_verify`.
# API Usage
Note that steps 1 to 6 can happen before the message to be signed is known to the signers.
Therefore, the communication round to exchange nonces can be viewed as a pre-processing step that is run whenever convenient to the signers.
This disables some of the defense-in-depth measures that may protect against API misuse in some cases.
Similarly, the API supports an alternative protocol flow where generating the aggregate key (steps 1 to 3) is allowed to happen after exchanging nonces (steps 4 to 6).
The following sections describe use of our API, and are mirrored in code in `src/modules/musig/example.c`.
# Verification
It is essential to security that signers use a unique uniformly random nonce for all
signing sessions, and that they do not reuse these nonces even in the case that a
signing session fails to complete. To that end, all signing state is encapsulated
in the data structure `secp256k1_musig_session`. The API does not expose any
functionality to serialize or deserialize this structure; it is designed to exist
only in memory.
A participant who wants to verify the partial signatures, but does not sign itself may do so using the above instructions except that the verifier skips steps 1, 4 and 7.
Users who need to persist this structure must take additional security measures
which cannot be enforced by a C API. Some guidance is provided in the documentation
for this data structure in `include/secp256k1_musig.h`.
## Key Generation
To use MuSig, users must first compute their combined public key `P`, which is
suitable for use on a blockchain or other public key repository. They do this
by calling `secp256k1_musig_pubkey_combine`.
This function takes as input a list of public keys `P_i` in the argument
`pubkeys`. It outputs the combined public key `P` in the out-pointer `combined_pk`
and hash `L` in the out-pointer `pk_hash32`, if this pointer is non-NULL.
## Signing
A participant who wishes to sign a message (as opposed to observing/auditing the
signature process, which is also a supported mode) acts as follows.
### Signing Participant
1. The signer starts the session by calling `secp256k1_musig_session_init`.
This function outputs
- an initialized session state in the out-pointer `session`
- an array of initialized signer data in the out-pointer `signers`
- a commitment `H(R_i)` to a nonce in the out-pointer `nonce_commitment32`
It takes as input
- a unique session ID `session_id32`
- (optionally) a message to be signed `msg32`
- the combined public key output from `secp256k1_musig_pubkey_combine`
- the public key hash output from `secp256k1_musig_pubkey_combine`
- the signer's index `i` `my_index`
- the signer's secret key `seckey`
2. The signer then communicates `H(R_i)` to all other signers, and receives
commitments `H(R_j)` from all other signers `j`. These hashes are simply
length-32 byte arrays which can be communicated however is communicated.
3. Once all signers nonce commitments have been received, the signer records
these commitments with the function `secp256k1_musig_session_get_public_nonce`.
If the signer did not provide a message to `secp256k1_musig_session_init`,
a message must be provided now.
This function updates in place
- the session state `session`
- the array of signer data `signers`
taking in as input the list of commitments `commitments` and outputting the
signer's public nonce `R_i` in the out-pointer `nonce`.
4. The signer then communicates `R_i` to all other signers, and receives `R_j`
from each signer `j`. On receipt of a nonce `R_j` he calls the function
`secp256k1_musig_set_nonce` to record this fact. This function checks that
the received nonce is consistent with the previously-received nonce and will
return 0 in this case. The signer must also call this function with his own
nonce and his own index `i`.
These nonces `R_i` are secp256k1 public keys; they should be serialized using
`secp256k1_ec_pubkey_serialize` and parsed with `secp256k1_ec_pubkey_parse`.
5. Once all nonces have been exchanged in this way, signers are able to compute
their partial signatures. They do so by calling `secp256k1_musig_session_combine_nonces`
which updates in place
- the session state `session`
- the array of signer data `signers`
It outputs an auxiliary integer `nonce_is_negated` and has an auxiliary input
`adaptor`. Both of these may be set to NULL for ordinary signing purposes.
6. The signer computes a partial signature `s_i` using the function
`secp256k1_musig_partial_sign` which takes the session state as input and
partial signature as output.
7. The signer then communicates the partial signature `s_i` to all other signers, or
to a central coordinator. These partial signatures should be serialized using
`musig_partial_signature_serialize` and parsed using `musig_partial_signature_parse`.
8. Each signer calls `secp256k1_musig_partial_sig_verify` on the other signers' partial
signatures to verify their correctness. If only the validity of the final signature
is important, not assigning blame, this step can be skipped.
9. Any signer, or central coordinator, may combine the partial signatures to obtain
a complete signature using `secp256k1_musig_partial_sig_combine`. This function takes
a signing session and array of MuSig partial signatures, and outputs a single
Schnorr signature.
### Non-signing Participant
A participant who wants to verify the signing process, i.e. check that nonce commitments
are consistent and partial signatures are correct without contributing a partial signature,
may do so using the above instructions except for the following changes:
1. A signing session should be produced using `musig_session_init_verifier`
rather than `musig_session_init`; this function takes no secret data or
signer index.
2. The participant receives nonce commitments, public nonces and partial signatures,
but does not produce these values. Therefore `secp256k1_musig_session_get_public_nonce`
and `secp256k1_musig_partial_sign` are not called.
### Verifier
The final signature is simply a valid Schnorr signature using the combined public key. It
can be verified using the `secp256k1_schnorrsig_verify` with the correct message and
public key output from `secp256k1_musig_pubkey_combine`.
## Atomic Swaps
# Atomic Swaps
The signing API supports the production of "adaptor signatures", modified partial signatures
which are offset by an auxiliary secret known to one party. That is,
1. One party generates a (secret) adaptor `t` with corresponding (public) adaptor `T = t*G`.
2. When combining nonces, each party adds `T` to the total nonce used in the signature.
3. The party who knows `t` must "adapt" their partial signature with `t` to complete the
signature.
4. Any party who sees both the final signature and the original partial signatures
can compute `t`.
Using these adaptor signatures, two 2-of-2 MuSig signing protocols can be executed in
parallel such that one party's partial signatures are made atomic. That is, when the other
party learns one partial signature, she automatically learns the other. This has applications
in cross-chain atomic swaps.
Such a protocol can be executed as follows. Consider two participants, Alice and Bob, who
are simultaneously producing 2-of-2 multisignatures for two blockchains A and B. They act
as follows.
1. Before the protocol begins, Bob chooses a 32-byte auxiliary secret `t` at random and
computes a corresponding public point `T` by calling `secp256k1_ec_pubkey_create`.
He communicates `T` to Alice.
2. Together, the parties execute steps 1-4 of the signing protocol above.
3. At step 5, when combining the two parties' public nonces, both parties call
`secp256k1_musig_session_combine_nonces` with `adaptor` set to `T` and `nonce_is_negated`
set to a non-NULL pointer to int.
4. Steps 6 and 7 proceed as before. Step 8, verifying the partial signatures, is now
essential to the security of the protocol and must not be omitted!
The above steps are executed identically for both signing sessions. However, step 9 will
not work as before, since the partial signatures will not add up to a valid total signature.
Additional steps must be taken, and it is at this point that the two signing sessions
diverge. From here on we consider "Session A" which benefits Alice (e.g. which sends her
coins) and "Session B" which benefits Bob (e.g. which sends him coins).
5. In Session B, Bob calls `secp256k1_musig_partial_sig_adapt` with his partial signature
and `t`, to produce an adaptor signature. He can then call `secp256k1_musig_partial_sig_combine`
with this adaptor signature and Alice's partial signature, to produce a complete
signature for blockchain B.
6. Alice reads this signature from blockchain B. She calls `secp256k1_musig_extract_secret_adaptor`,
passing the complete signature along with her and Bob's partial signatures from Session B.
This function outputs `t`, which until this point was only known to Bob.
7. In Session A, Alice is now able to replicate Bob's action, calling
`secp256k1_musig_partial_sig_adapt` with her own partial signature and `t`, ultimately
producing a complete signature on blockchain A.
[1] https://eprint.iacr.org/2018/068
[2] https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki
2. When calling `secp256k1_musig_nonce_process`, the public adaptor `T` is provided as the `adaptor` argument.
3. The party who is going to extract the secret adaptor `t` later must verify all partial signatures.
4. Due to step 2, the signature output of `secp256k1_musig_partial_sig_agg` is a pre-signature and not a valid Schnorr signature. All parties involved extract this session's `nonce_parity` with `secp256k1_musig_nonce_parity`.
5. The party who knows `t` must "adapt" the pre-signature with `t` (and the `nonce_parity` using `secp256k1_musig_adapt` to complete the signature.
6. Any party who sees both the final signature and the pre-signature (and has the `nonce_parity`) can extract `t` with `secp256k1_musig_extract_adaptor`.