From 8d04ac318f2f6f160480faf6aeb843a1cba28db0 Mon Sep 17 00:00:00 2001 From: Jonas Nick Date: Fri, 1 Apr 2022 21:26:00 +0000 Subject: [PATCH 1/6] musig-spec: remove unnecessary and inconsistent input paragraph --- doc/musig-spec.mediawiki | 6 ------ 1 file changed, 6 deletions(-) diff --git a/doc/musig-spec.mediawiki b/doc/musig-spec.mediawiki index a65c54050..c992e6774 100644 --- a/doc/musig-spec.mediawiki +++ b/doc/musig-spec.mediawiki @@ -305,12 +305,6 @@ Input: * Run ''PartialSigVerifyInternal(psig, pubnoncei, pki, session_ctx)'' * Return success iff no failure occurred before reaching this point. -Input: -* The partial signature ''psig'': a 32-byte array -* The public nonce of the signer ''pubnonce'': a 66-byte array -* The public key of the signer ''pk*'' (in ''pk1..u'' of the session_ctx''): a 32-byte array -* The ''session_ctx'': a [[#session-context|Session Context]] data structure - '''''PartialSigVerifyInternal(psig, pubnonce, pk*, session_ctx)''''': * Let ''(Q, gaccv, _, b, R, e) = GetSessionValues(session_ctx)''; fail if that fails * Let ''s = int(psig)''; fail if ''s ≥ n'' From 1a086ba9c9143ef572b6f1fa3d7c6b8ca173414e Mon Sep 17 00:00:00 2001 From: Jonas Nick Date: Fri, 1 Apr 2022 21:26:55 +0000 Subject: [PATCH 2/6] musig-spec: add optional arguments to strengthen nonce function This is a defense-in-depth measure that may help if the value is not drawn uniformly at random. The handling of sk is similar to BIP340. --- doc/musig-spec.mediawiki | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/doc/musig-spec.mediawiki b/doc/musig-spec.mediawiki index c992e6774..4987b0e1c 100644 --- a/doc/musig-spec.mediawiki +++ b/doc/musig-spec.mediawiki @@ -78,7 +78,8 @@ The output of ''KeyAgg'' is dependent on the order of the input public keys. If there is no common order of the signers already, the public keys can be sorted with the ''KeySort'' algorithm to ensure that the same aggregate key is calculated. Note that public keys are allowed to occur multiple times in the input of ''KeyAgg'' and ''KeySort'', and that it is possible to successfully complete a MuSig2 signing session with duplicated public keys. -In some applications, it is beneficial to generate and exchange ''pubnonces'' before the message to sign or the final set of signers is known. +In some applications, it is beneficial to generate and exchange ''pubnonces'' before the signer's secret key, the final set of signers, or the message to sign is known. +In this case, only the available arguments are provided to the ''NonceGen'' algorithm. After this preprocessing phase, the ''Sign'' algorithm can be run immediately when the message and set of signers is determined. This way, the final signature is created quicker and with fewer roundtrips. However, applications that use this method presumably store the nonces for a longer time and must therefore be even more careful not to reuse them. @@ -125,6 +126,7 @@ The following conventions are used, with constants as defined for [https://www.s ** The function ''x[i:j]'', where ''x'' is a byte array and ''i, j ≥ 0'', returns a ''(j - i)''-byte array with a copy of the ''i''-th byte (inclusive) to the ''j''-th byte (exclusive) of ''x''. ** The function ''bytes(x)'', where ''x'' is an integer, returns the 32-byte encoding of ''x'', most significant byte first. ** The function ''bytes(P)'', where ''P'' is a point, returns ''bytes(x(P))''. +** The function ''len(x)'' where ''x'' is a byte array returns the length of the array. ** The function ''has_even_y(P)'', where ''P'' is a point for which ''not is_infinite(P)'', returns ''y(P) mod 2 = 0''. ** The function ''with_even_y(P)'', where ''P'' is a point, returns ''P'' if ''is_infinite(P)'' or ''has_even_y(P)''. Otherwise, ''with_even_y(P)'' returns ''-P''. ** The function ''cbytes(P)'', where ''P'' is a point, returns ''a || bytes(P)'' where ''a'' is a byte that is ''2'' if ''has_even_y(P)'' and ''3'' otherwise. @@ -212,8 +214,19 @@ Input: ==== Nonce Generation ==== -'''''NonceGen()''''': -* Generate two random integers ''k1, k2'' in the range ''1...n-1'' +Input: +* The secret signing key ''sk'': a 32-byte array or 0-byte array (optional argument) +* The aggregate public key ''aggpk'': a 32-byte array or 0-byte array (optional argument) +* The message ''m'': a 32-byte array or 0-byte array (optional argument) +* The auxiliary input ''in'': a byte array of length ''≥ 0'' (optional argument) + +'''''NonceGen(sk, aggpk, m, in)''''': +* Let ''rand' '' be a 32-byte array freshly drawn uniformly at random +* If ''len(sk) > 0'': +** Let ''rand'' be the byte-wise xor of ''sk'' and ''hashMuSig/aux(rand')''The random data is hashed (with a unique tag) as a precaution against situations where the randomness may be correlated with the secret signing key itself. It is xored with the secret key (rather than combined with it in a hash) to reduce the number of operations exposed to the actual secret key.. +* Else: let ''rand = rand' '' +* Let ''ki = int(hashMuSig/nonce(rand || len(aggpk) || aggpk || i || len(m) || m || len(in) || in)) mod n'' for ''i = 1,2'' +* Fail if ''k1 = 0'' or ''k2 = 0'' * Let ''R*1 = k1⋅G, R*2 = k2⋅G'' * Let ''pubnonce = cbytes(R*1) || cbytes(R*2)'' * Let ''secnonce = bytes(k1) || bytes(k2)'' From a29b961eb75d4bd4c871ee5cc7de861a2b7011aa Mon Sep 17 00:00:00 2001 From: Jonas Nick Date: Sun, 3 Apr 2022 23:41:50 +0000 Subject: [PATCH 3/6] musig-spec: add acknowledgements and improve abstract --- doc/musig-spec.mediawiki | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/doc/musig-spec.mediawiki b/doc/musig-spec.mediawiki index 4987b0e1c..68d295142 100644 --- a/doc/musig-spec.mediawiki +++ b/doc/musig-spec.mediawiki @@ -14,7 +14,7 @@ This document proposes a standard for the [https://eprint.iacr.org/2020/1261.pdf MuSig2] protocol. The standard is compatible with [https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki BIP340] public keys and signatures. -It also supports ''tweaking'', which allows creating [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP341] Taproot outputs with key and script paths. +It supports ''tweaking'', which allows deriving [https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP32] child keys from aggregate keys and creating [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP341] Taproot outputs with key and script paths. === Copyright === @@ -495,3 +495,5 @@ A scheme very similar to MuSig2 and with two-point nonces was independently prov == Acknowledgements == + +We thank Brandon Black, Riccardo Casatta, Russell O'Connor, and Pieter Wuille for their contributions to this document. From e463ea42bb1fe48e30e6d289461cff4fa0935f77 Mon Sep 17 00:00:00 2001 From: Jonas Nick Date: Sun, 3 Apr 2022 23:42:40 +0000 Subject: [PATCH 4/6] musig-spec: mention stateless signing in signing flow --- doc/musig-spec.mediawiki | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/doc/musig-spec.mediawiki b/doc/musig-spec.mediawiki index 68d295142..4f4149f48 100644 --- a/doc/musig-spec.mediawiki +++ b/doc/musig-spec.mediawiki @@ -90,6 +90,11 @@ This technique reduces the overall communication. The aggregator node does not need to be trusted for the scheme's security to hold. All the aggregator node can do is prevent the signing session from succeeding by sending out incorrect aggregate nonces. +In general, MuSig2 signers are stateful in the sense that they first generate ''secnonce'' and then need to store it until they receive the other signer's ''pubnonces'' or the ''aggnonce''. +However, it is possible for one of the signers to be stateless. +This signer waits until it receives the ''pubnonce'' of all the other signers and until session parameters such as a message to sign, public keys, and tweaks are determined. +Then, the signer can run ''NonceGen'', ''NonceAgg'' and ''Sign'' in sequence and send out its ''pubnonce'' along with its partial signature. + If any signer sends an incorrect partial signature, i.e., one that has not then been created with ''Sign'' and the right arguments for the session, the MuSig2 protocol may fail to output a valid Schnorr signature. This standard provides the method ''PartialSigVerify'' to verify the correctness of partial signatures. If partial signatures are authenticated, this method can be used to identify disruptive signers and hold them accountable. From f56e223a7a79aa52748d4f542ecebc2ce6c537b2 Mon Sep 17 00:00:00 2001 From: Jonas Nick Date: Sun, 3 Apr 2022 23:43:05 +0000 Subject: [PATCH 5/6] musig-spec: explain NonceGen and tweaking in signing flow context --- doc/musig-spec.mediawiki | 38 ++++++++++++++++++++++++++++++++++---- 1 file changed, 34 insertions(+), 4 deletions(-) diff --git a/doc/musig-spec.mediawiki b/doc/musig-spec.mediawiki index 4f4149f48..390e27944 100644 --- a/doc/musig-spec.mediawiki +++ b/doc/musig-spec.mediawiki @@ -71,8 +71,6 @@ If all signers behaved honestly, the result passes [https://github.com/bitcoin/b Otherwise, extracting the secret signing key from the partial signatures is possible. To avoid accidental reuse, an implementation may securely erase the ''secnonce'' argument by overwriting it with zeros after ''Sign'' has been run. A ''secnonce'' consisting of only zeros is invalid for ''Sign'' and will cause it to fail. -The ''NonceGen'' algorithm '''must''' draw unbiased, uniformly random values ''k1'' and ''k2''. -In particular, ''k1'' and ''k2'' must _not_ be derived deterministically from the session parameters (see [[#nonce-generation|Nonce Generation]]). The output of ''KeyAgg'' is dependent on the order of the input public keys. If there is no common order of the signers already, the public keys can be sorted with the ''KeySort'' algorithm to ensure that the same aggregate key is calculated. @@ -108,11 +106,43 @@ As a result, the [[#session-context|Session Context]] may look very different in ==== Nonce Generation ==== -TODO +'''IMPORTANT''': ''NonceGen'' must have access to a high-quality random generator to draw an unbiased, uniformly random value ''rand' ''. +Additionally, implementors must avoid modifying the ''NonceGen'' algorithm without being fully aware of the implications. +In contrast to BIP340 signing, the values ''k1'' and ''k2'' must _not_ be derived deterministically from the session parameters because otherwise active attackers can [https://medium.com/blockstream/musig-dn-schnorr-multisignatures-with-verifiably-deterministic-nonces-27424b5df9d6#e3b6 trick the victim into reusing a nonce]. + +The optional arguments to ''NonceGen'' enable a defense-in-depth mechanism that may prevent secret key exposure if ''rand' '' is accidentally not drawn uniformly at random. +If the value ''rand' '' would be identical in two ''NonceGen'' invocations, but any optional argument is unequal, the values ''k1'' and ''k2'' are unequal as well (with overwhelming probability). +In this case, accidentally using the same ''secnonce'' for ''Sign'' in both sessions would be avoided. +Therefore, it is recommended to provide the optional arguments ''sk'', ''aggpk'', and ''m'' if these session parameters are already determined during nonce generation. +The auxiliary input ''in'' can contain additional contextual data that has a chance of changing between ''NonceGen'' runs. +However, the protection from the optional arguments should only be viewed as a last resort. +In most conceivable scenarios, the assumption that the arguments are different between two executions of ''NonceGen'' is relatively strong, particularly when facing an active attacker. + +On systems where obtaining uniformly random values is much harder than maintaining a global atomic counter, it can be beneficial to modify ''NonceGen''. +Instead of drawing ''rand' '' uniformly at random, ''rand' '' can be the output of an atomic counter. +With this modification, the secret signing key ''sk'' of the signer generating the nonce is _not_ an optional argument and must be provided to ''NonceGen''. +The counter must never return the same output in two ''NonceGen'' invocations with the same ''sk''. + +It is possible to modify ''NonceGen'' such that the ''secnonce'' of a single signer can be derived deterministically. +For a deterministic nonce generation algorithm ''NonceGen' '', the arguments ''sk'', ''aggpk'' and ''m'' are not optional and must be set precisely to the signer's secret key and the aggregate public key and message of the session. +In addition, ''NonceGen' '' requires the ''pubnonce'' value of _all_ other signers, which can be provided via the ''in'' argument. +Hence, using ''NonceGen' '' is only possible for the last signer to generate a nonce and makes the signer stateless, similar to the signer mentioned in the [[#signing-flow|Signing Flow]] section. +Lastly, to make ''NonceGen' '' deterministic, ''rand' '' is removed and ''rand'' is set to ''sk''. +Note that failure to provide the correct arguments to ''NonceGen' '' will allow attackers to extract secret keys. ==== Tweaking ==== -TODO +In addition to public keys, the ''KeyAgg'' algorithm accepts tweaks, which modify the aggregate public key as defined in the [[#tweaking-definition|Tweaking Definition]] subsection. +For example, if ''KeyAgg'' is run with ''v = 2'', ''is_xonly_t1 = false'', ''is_xonly_t2 = true'', then the aggregate key is first ordinarily tweaked with ''tweak1'' and then X-only tweaked with ''tweak2''. + +The purpose of specifying tweaking is to ensure compatibility with existing uses of tweaking, i.e., that the result of signing is a valid signature for the tweaked public key. +The MuSig2 algorithms take arbitrary tweaks as input but accepting arbitrary tweaks may negatively affect the protocol's security. +Instead, signers should obtain the tweaks according to other specifications. +This typically involves deriving the tweaks from a hash of the aggregate public key and some other information. + +Ordinary tweaking can be used to derive child public keys from an aggregate public key using [https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP32]. +On the other hand, X-only tweaking is required for Taproot tweaking per [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP341]. +A Taproot-tweaked public key commits to a ''script path'', allowing users to create transaction outputs that are spendable either with a MuSig2 multi-signature or by providing inputs that satisfy the script path. === Notation === From fd51a6281ec21c9dcb71c13666a2551370e31fd1 Mon Sep 17 00:00:00 2001 From: Jonas Nick Date: Mon, 4 Apr 2022 10:57:30 +0000 Subject: [PATCH 6/6] musig-spec: add authors --- doc/musig-spec.mediawiki | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/doc/musig-spec.mediawiki b/doc/musig-spec.mediawiki index 390e27944..a1f862803 100644 --- a/doc/musig-spec.mediawiki +++ b/doc/musig-spec.mediawiki @@ -1,7 +1,9 @@
   BIP: ?
   Title: MuSig2
-  Author:
+  Author: Jonas Nick 
+          Tim Ruffing 
+          Elliott Jin 
   Status: Draft
   License: BSD-3-Clause
   Type: Informational