<p><strong>Nonces must not be reused!</strong> In particular, in MuSig, nonces can not be reused
for other combinations of public keys or messages (also if everyone uses the
same public nonces all the time). This would leak private keys.</p>

<p>You pre-share fresh nonces by running multiple signing rounds in parallel.
With the library you link to
(<a href="https://github.com/ElementsProject/secp256k1-zkp" rel="noreferrer">secp256k1-zkp</a>) this is
secure as you long as you keep the session states in memory and don't copy it.
Serializing the state and storing it on a persistent medium is not supported by
secp256k1-zkp and difficult to get right because if you accidentally use the
wrong nonce, you leak the private key.</p>

<p>A straightforward way to eliminate the overhead of the first two interaction
rounds is by attaching the nonce commitment and nonce to already existing
messages in your protocol. That way you would only have two parallel signing
sessions.</p>

<p>There is research being done on deterministic nonces for MuSig which have
zero-knowledge proofs that the nonce is derived correctly. With such proofs
nonces can be derived on demand from the signer set, your private key and the
message and there is no state to keep track of.</p>

CC BY-SA 4.0
2019-05-08T21:48:58.473Z
Also no way to use something like a BIP-32 hierarchical deterministic key generation to get public nonces from a pre-shared root and agreed derivation path?
Richard Myers
CC BY-SA 4.0
2019-05-08T21:52:46.047Z
No, creativity will only make things harder to analyze, but won't help you bypass fundamental problems. MuSig has three interaction rounds for a reason; if there was a known way to avoid that, we wouldn't have written a paper that uses three rounds.
Pieter Wuille
CC BY-SA 4.0
2019-05-08T22:04:01.167Z
Thanks for the answers - hopefully you won't have to answer this line of dumb questions on SO again for awhile. :-)
Richard Myers
CC BY-SA 4.0
2019-05-10T17:46:59.943Z
We should start a betting pool for the date of the first reported funds loss due to an insecure threshold signature implementation.
G. Maxwell
CC BY-SA 4.0
2019-05-08T21:37:30.370Z
2019-05-08T21:45:43.023Z
2019-05-08T21:45:43.023Z
nickler
<p>I'm trying to find a way to amortize the interactive session setup in the <a href="https://eprint.iacr.org/2018/068.pdf" rel="nofollow noreferrer">MuSig</a> signature aggregation scheme.  My motivation is to use signature aggregation between devices communicating using low bandwidth (radio) channels without having to do the session setup multiple times. Ideally pre-shared <strong>public nonces</strong> could be reused for different signer sets, public keys and messages.</p>

<p>I've summarized below how I understand it works now, mostly from looking at the code example <a href="https://github.com/ElementsProject/secp256k1-zkp/blob/secp256k1-zkp/src/modules/musig/example.c" rel="nofollow noreferrer">here</a>:</p>

<ul>
<li><p>each peer creates a per <em>session secret key</em> from the hash of the set of signers public keys and the secret key for the peer's public key (independent of the nonce)</p></li>
<li><p>each peer creates a <strong>secret nonce</strong> from the signers public keys and other hashed information, including a random number</p></li>
<li><p>each peer creates a <strong>public nonce</strong>, generated like a public key from the <strong>secret nonce</strong>.</p></li>
<li><p>all peers send to all other peers a 32-byte <strong>nonce commitment</strong></p></li>
<li><p>all peers send to all other peers their 32-byte <strong>public nonce</strong> and verify the others against their previously shared <strong>nonce commitments</strong></p></li>
</ul>

<blockquote>
  <p>the key point seems to be that the <strong>public nonce</strong> should NOT be freely chosen by anyone after learning the <strong>public nonces</strong> of the other signers</p>
</blockquote>

<ul>
<li><p>each peer can now sign using their <em>session secret key</em> and <strong>secret nonce</strong></p></li>
<li><p>other peers can verify the final (or partial) multi-signature using the other signers chosen public keys and their corresponding <strong>public nonces</strong>.</p></li>
<li><p>What I wonder is if the <strong>public nonce</strong> can be committed to once in advance by all peers, and then reused for different combinations of (public key, other peers public keys, messages).</p></li>
</ul>

<p>It seems like peers could cache each others <strong>public nonces</strong> and reuse them for different signing sessions with different public keys and other signers as long as all signers were compelled to use the same <strong>public nonce</strong> every time they signed.</p>

<p>Any pointers on the restrictions for reusing these MuSig <strong>public nonces</strong> would be appreciated.</p>

CC BY-SA 4.0
2019-05-08T21:31:10.597Z
If you ever reuse the same public nonce, the other participants learn you private key. You can preshare lists of public nonce commitments to avoid some steps, but all participants must go through the list in lockstep. If someone is ever confused about the position in the list, they likely leak their private key.
Pieter Wuille
<schnorr-signatures>
What are the limitations for amortizing the interactive session setup of MuSig?
Richard Myers
# What are the limitations for amortizing the interactive session setup of MuSig?

(Asked by: username_0 on 2019-05-08)

I'm trying to find a way to amortize the interactive session setup in the [MuSig](https://eprint.iacr.org/2018/068.pdf) signature aggregation scheme. My motivation is to use signature aggregation between devices communicating using low bandwidth (radio) channels without having to do the session setup multiple times. Ideally pre-shared **public nonces** could be reused for different signer sets, public keys and messages.

I've summarized below how I understand it works now, mostly from looking at the code example [here](https://github.com/ElementsProject/secp256k1-zkp/blob/secp256k1-zkp/src/modules/musig/example.c):

* each peer creates a per *session secret key* from the hash of the set of signers public keys and the secret key for the peer's public key (independent of the nonce)
* each peer creates a **secret nonce** from the signers public keys and other hashed information, including a random number
* each peer creates a **public nonce**, generated like a public key from the **secret nonce**.
* all peers send to all other peers a 32-byte **nonce commitment**
* all peers send to all other peers their 32-byte **public nonce** and verify the others against their previously shared **nonce commitments**

> the key point seems to be that the **public nonce** should NOT be freely chosen by anyone after learning the **public nonces** of the other signers

* each peer can now sign using their *session secret key* and **secret nonce**
* other peers can verify the final (or partial) multi-signature using the other signers chosen public keys and their corresponding **public nonces**.
* What I wonder is if the **public nonce** can be committed to once in advance by all peers, and then reused for different combinations of (public key, other peers public keys, messages).

It seems like peers could cache each others **public nonces** and reuse them for different signing sessions with different public keys and other signers as long as all signers were compelled to use the same **public nonce** every time they signed.

Any pointers on the restrictions for reusing these MuSig **public nonces** would be appreciated.

**Tags:** schnorr-signatures

> **Comments:**
> **username_1**: If you ever reuse the same public nonce, the other participants learn you private key. You can preshare lists of public nonce commitments to avoid some steps, but all participants must go through the list in lockstep. If someone is ever confused about the position in the list, they likely leak their private key.  

---

## 1 answers

### Answer by username_2 on 2019-05-08. Score: 8 | Accepted answer

**Nonces must not be reused!** In particular, in MuSig, nonces can not be reused
for other combinations of public keys or messages (also if everyone uses the
same public nonces all the time). This would leak private keys.

You pre-share fresh nonces by running multiple signing rounds in parallel.
With the library you link to
([secp256k1-zkp](https://github.com/ElementsProject/secp256k1-zkp)) this is
secure as you long as you keep the session states in memory and don't copy it.
Serializing the state and storing it on a persistent medium is not supported by
secp256k1-zkp and difficult to get right because if you accidentally use the
wrong nonce, you leak the private key.

A straightforward way to eliminate the overhead of the first two interaction
rounds is by attaching the nonce commitment and nonce to already existing
messages in your protocol. That way you would only have two parallel signing
sessions.

There is research being done on deterministic nonces for MuSig which have
zero-knowledge proofs that the nonce is derived correctly. With such proofs
nonces can be derived on demand from the signer set, your private key and the
message and there is no state to keep track of.

> **Comments:**
> **username_0**: Also no way to use something like a BIP-32 hierarchical deterministic key generation to get public nonces from a pre-shared root and agreed derivation path?  
> **username_1**: No, creativity will only make things harder to analyze, but won't help you bypass fundamental problems. MuSig has three interaction rounds for a reason; if there was a known way to avoid that, we wouldn't have written a paper that uses three rounds.  
> **username_0**: Thanks for the answers - hopefully you won't have to answer this line of dumb questions on SO again for awhile. :-)  
> **username_3**: We should start a betting pool for the date of the first reported funds loss due to an insecure threshold signature implementation.  

---

