musig

https://github.com/ElementsProject/secp256k1-zkp

https://github.com/HouMYt/musigSchnorr

 

上周一，我们发表了一篇论文，介绍了MuSig，一种基于 Schnorr 签名的多重签名方案。这篇文章将深入探讨它的构建以及它在比特币上的一些应用。

MuSig 是一个简单的多重签名方案，它在组合方面很新颖：

1. 支持密钥聚合
2. 普通公钥模型中的安全性

MuSig 有两个版本，根据通信轮数的不同而有所不同。两者都可以证明是安全的，但三轮 MuSig 仅依赖于离散对数 (DL) 假设，ECDSA 也依赖于此。相反，两轮 MuSig 依赖于稍强的 One-More Discrete Logarithm (OMDL) 假设。

虽然这项工作是我们对比特币 Schnorr 签名研究的结果，但 MuSig 是一种加密结构，可能对其他应用程序有用。这篇论文和这篇文章主要讨论了 MuSig 的加密特性，并不直接针对比特币提出建议。

阿多签名方案是一个签名和验证算法，其中多个签名者（每个都有自己的私钥/公钥）共同签署一个消息，产生一个单一的签名的组合。然后，任何知道消息和签名者公钥的人都可以验证这个单一签名。请注意，在比特币的上下文中，术语“多重签名”通常指的是k- of- n策略，其中k可以与n不同。在密码学文献中，多重签名实际上仅指n -of- n策略，尽管我们可以轻松地在n之上构造k -of- n-of- n。

我们使用术语密钥聚合来指代看起来像单密钥签名的多重签名，但对于聚合公钥而言，它仅是参与者公钥的函数。这意味着验证者实际上不再需要知道原始参与者的公钥——他们可以只获得聚合密钥。在某些用例中，这会带来更好的隐私和性能。MuSig 实际上是 Schnorr 签名的密钥聚合方案。

已经存在几种多重签名方案，它们可以有效地为我们提供 Schnorr 签名的密钥聚合，但它们带有一些警告，例如需要验证参与者实际上拥有与他们声称拥有的公钥相对应的私钥。普通公钥模型中的安全性意味着不存在此类警告。我们需要的只是参与者的公钥。

多重签名在比特币中的应用

最明显的用途情况下，在比特币的上下文中的多签名是作为一种更有效的替代Ñ -OF- Ñ multisig脚本和其他策略，其允许许多键的可能组合（包括ķ -OF- Ñ，使用关键树、MAST或传统的阈值方案）。对于这些，原生多重签名方案意味着我们为每个交易输入留下一个签名. 密钥聚合方案还允许我们将每个输入的公钥数量减少到一个，因为用户可以将硬币发送到所有相关密钥的聚合中，而不是将它们全部包含在脚本中。这导致更小的链上足迹、更快的验证和更好的隐私。因此，MuSig 在这里是一个不错的选择。

然而，我们可以走得更远。我们实际上可以为整个交易获得一个签名，而不是将自己限制为每个输入一个签名。密钥聚合不能跨多个输入使用，因为公钥由输出提交，并且可以独立使用。MuSig 可以在这里使用（由验证者完成密钥聚合），但是Bellare-Neven (BN)，一种不支持密钥聚合的更广为人知的普通公钥多重签名方案也能正常工作。有趣的是，可以使用 BN 多重签名，其中单个密钥是 MuSig 聚合。

从技术上讲，为了将所有交易输入的签名合二为一，我们不需要多重签名方案，而是聚合签名方案。区别很简单，在聚合签名中，每个签名者都有自己的消息，而不是所有人共享的一条消息。聚合签名可分为交互式或非交互式：交互式聚合签名 (IAS) 需要签名者合作，而非交互式方案允许任何人进行聚合。没有已知的非交互式聚合方案仅依赖于 DL 假设，但交互式聚合方案的构建很简单：采用多重签名方案，让每个参与者对所有消息的串联进行签名。我们的论文表明，这并不总是理想的结构，

细节

符号：

• x , x ₁ , x ₂ , ... 是私钥，对应的公钥X , X ₁ , X ₂ , ... ( X _i = x _i G , G是生成器)
• 被签名的消息是m
• H()是一个加密哈希函数

施诺尔签名

作为复习，以下是与 Schnorr 签名相关的等式：

• 签名是(R,s) = (rG, r + H(X,R,m)x)其中r是签名者选择的随机数
• 验证需要sG = R + H(X,R,m)X

Naive Schnorr 多重签名

一个简单的概括可以支持多重签名：

• 称X为X _i个点的总和
• 每个签名者选择一个随机随机数r _i，并与其他签名者共享R _i = r _i G
• 称R为R _i点的总和
• 每个签名者计算s _i = r _i + H(X,R,m)x _i
• 最终签名是(R,s)其中s是s _i值的总和
• 验证需要sG = R + H(X,R,m)X，其中X是各个公钥的总和

有趣的是，这满足上述密钥聚合方案的定义：多方可以联合生成一个签名，该签名是密钥总和的有效单密钥签名。既然这么简单，又有什么好大惊小怪的呢？

问题当然是这个方案不安全。考虑以下场景。Alice 和 Bob 想一起产生一个多重签名。Alice 有一个密钥对(x _A ,X _A )而 Bob 有(x _B ,X _B )。然而，没有什么能阻止 Bob 声称他的公钥是X _B ' = X _B - X _A。如果他这样做，其他人会假设X _A + X _B '是 Alice 和 Bob 需要合作才能签名的聚合密钥。不幸的是，该总和等于X _B，Bob 可以自己清楚地签署这一点。这称为流氓密钥攻击，避免它的一种方法是要求 Alice 和 Bob 首先证明他们确实拥有与他们声称的公钥相对应的私钥。然而，这种缓解并不总是可行的，即使是这样，它充其量也是脆弱的。理想情况下，我们构建了一个安全性不依赖于密钥的带外验证的方案。

贝拉尔-尼文

如上所述，BN多重签名方案在没有这些假设的情况下是安全的。下面是它的工作原理：

• 呼叫L = H(X ₁ ,X ₂ ,...)
• 每个签名者选择一个随机随机数r _i，并与其他签名者共享R _i = r _i G
• 称R为R _i点的总和
• 每个签名者计算s _i = r _i + H(L,X _i ,R,m)x _i
• 最终签名是(R,s)其中s是s _i值的总和
• 验证需要sG = R + H(L,X ₁ ,R,m)X ₁ + H(L,X ₂ ,R,m)X ₂ + …

从技术上讲，BN 有一个预提交回合，签名者首先向彼此透露H(R _i )，然后再透露自己的R _i点。这一步对于证明 DL 假设下的安全性是必要的，但如果我们接受 OMDL 假设，则可以避免。这也是二轮和三轮MuSig的区别。

2019-02-19 更新：根据 Drijvers 等人的这篇论文。，我们意识到上面的段落是不正确的。在 MuSig 中简单地跳过预承诺回合是不安全的。

此外，当需要 IAS 时（其中每个签名者都有自己的消息），我们论文的附录 A 建议使用L = H((X ₁ ,m ₁ ),(X ₂ ,m ₂ ),...)代替，并且s _i = r _i + H(L,R,i)x _i用于签名（与验证类似）。

在任何情况下，生成的签名不再满足正常的 Schnorr 方程，也不再满足任何其他可以写成公钥组合函数的方程。换句话说，为了在普通公钥模型中获得安全性，我们已经失去了密钥聚合属性。

信号

这就是MuSig 的用武之地。它可以在不失去安全性的情况下恢复密钥聚合属性：

• 呼叫L = H(X ₁ ,X ₂ ,...)
• 称X为所有H(L,X _i )X _i的总和
• 每个签名者选择一个随机随机数r _i，并与其他签名者共享R _i = r _i G
• 称R为R _i点的总和
• 每个签名者计算s _i = r _i + H(X,R,m)H(L,X _i )x _i
• 最终签名是(R,s)其中s是s _i值的总和
• 再次验证满足sG = R + H(X,R,m)X

而已！我们所要做的就是将X定义为单个公钥X _i的简单总和，而是定义为这些密钥的倍数之和，其中乘法因子取决于所有参与密钥的散列。

致谢

我们非常感谢 Yannick Seurin，感谢他对审查 MuSig 的安全性、编写其安全性证明以及提出名称的兴趣。

 

 

 

 

 

 

 

 

 

Last Monday we published a paper that introduces MuSig, a multi-signature scheme based on Schnorr signatures. This post will dive into its construction and a few of its applications to Bitcoin.

MuSig is a simple multi-signature scheme that is novel in combining:

1. support for key aggregation
2. security in the plain public-key model

There are two versions of MuSig, which vary based on the number of communication rounds. Both are provably secure, but three-round MuSig only relies on the Discrete Logarithm (DL) assumption, which ECDSA also relies on. Two-round MuSig instead relies on the slightly stronger One-More Discrete Logarithm (OMDL) assumption.

While this work is a result of our research into Schnorr signatures for Bitcoin, MuSig is a cryptographic construction that may be useful for other applications. The paper and this post primarily discuss the cryptographic properties of MuSig, and aren’t directly a proposal for Bitcoin.

A multi-signature scheme is a combination of a signing and verification algorithm, where multiple signers (each with their own private/public key) jointly sign a single message, resulting in a single signature. This single signature can then be verified by anyone who also knows the message and the public keys of the signers. Note that in the context of Bitcoin, the term “multisig” usually refers to a k-of-n policy, where k can be different from n. In the cryptographic literature, multi-signatures really only refers to n-of-n policies, though we can easily construct k-of-n on top of n-of-n.

We’re using the term key aggregation to refer to multi-signatures that look like a single-key signature, but with respect to an aggregated public key that is a function of only the participants’ public keys. This means that verifiers don’t actually need to know the original participants’ public keys anymore - they can just be given the aggregated key instead. In some use cases, this leads to better privacy and performance. MuSig is effectively a key aggregation scheme for Schnorr signatures.

Several multi-signature schemes exist already that effectively give us key aggregation for Schnorr signatures, but they come with some caveats like needing to verify that participants actually have the private key corresponding to the public keys they claim to have. Security in the plain public-key model means that no such caveats exist. All we need from the participants is their public keys.

Applications of multi-signatures in Bitcoin

The most obvious use case for multi-signatures in the context of Bitcoin is as a more efficient replacement for n-of-n multisig scripts, and other policies that permit a number of possible combinations of keys (including k-of-n, using key trees, MAST, or traditional threshold schemes). For these, a native multi-signature scheme means we are left with one signature per transaction input. A key aggregation scheme also lets us reduce the number of public keys per input to one, as a user can send coins to the aggregate of all involved keys, rather than including them all in the script. This leads to smaller on-chain footprint, faster validation, and better privacy. As a result, MuSig is a good choice here.

However, we can go further. Instead of restricting ourselves to one signature per input, we can actually get one signature for the entire transaction. Key aggregation can’t be used across multiple inputs, as the public keys are committed to by the outputs, and those can be spent independently. MuSig can be used here (with key aggregation done by the verifier), but Bellare-Neven (BN), a more widely known plain public-key multi-signature scheme that does not support key aggregation would work just as well. Interestingly, it is possible to use BN multi-signatures where the individual keys are MuSig aggregates.

Technically, in order to combine all the transaction inputs’ signatures into one, we don’t need a multi-signature scheme, but an aggregate signature scheme. The distinction is simply that in an aggregate signature, each signer has their own message, rather than one message shared by all. Aggregate signatures can be classified as interactive or non-interactive: interactive aggregate signatures (IAS) require the signers to cooperate, while non-interactive schemes allow the aggregation to be done by anyone. No non-interactive aggregation schemes are known that only rely on the DL assumption, but interactive ones are trivial to construct: take a multi-signature scheme and have every participant sign the concatenation of all messages. Our paper shows that this is not always a desirable construction, and gives an IAS variant of BN with better properties instead.

Details

Notation:

• x, x₁, x₂, … are private keys with corresponding public keys X, X₁, X₂, … (X_i = x_iG, with G the generator)
• The message being signed is m
• H() is a cryptographic hash function

Schnorr signatures

As a refresher, here are the equations relevant for Schnorr signatures:

• Signatures are (R,s) = (rG, r + H(X,R,m)x) where r is a random nonce chosen by the signer
• Verification requires sG = R + H(X,R,m)X

Naive Schnorr multi-signatures

A straightforward generalization is possible to support multi-signatures:

• Call X the sum of the X_i points
• Each signer chooses a random nonce r_i, and shares R_i = r_iG with the other signers
• Call R the sum of the R_i points
• Each signer computes s_i = r_i + H(X,R,m)x_i
• The final signature is (R,s) where s is the sum of the s_i values
• Verification requires sG = R + H(X,R,m)X, where X is the sum of the individual public keys

Interestingly, this satisfies the definition of a key aggregation scheme above: multiple parties can jointly produce a signature that is a valid single-key signature for the sum of the keys. If it’s so simple, what’s all the fuss about?

The issue is of course that this scheme is not secure. Consider the following scenario. Alice and Bob want to produce a multi-signature together. Alice has a key pair (x_A,X_A) and Bob has (x_B,X_B). However, nothing prevents Bob from that claiming his public key is X_B’ = X_B - X_A. If he does so, others will assume that X_A + X_B’ is the aggregated key that Alice and Bob need to cooperate in order to sign for. Unfortunately, that sum is equal to X_B, and Bob can clearly sign for this by himself. This is called a rogue-key attack, and one way to avoid it is requiring that Alice and Bob prove first that they actually possess the private keys corresponding to their claimed public keys. However, this mitigation is not always possible, and even when it is, it is fragile at best. Ideally we construct a scheme whose security does not rely on out-of-band verification of the keys.

Bellare-Neven

As mentioned above, the BN multi-signature scheme is secure without such assumptions. Here is how it works:

• Call L = H(X₁,X₂,…)
• Each signer chooses a random nonce r_i, and shares R_i = r_iG with the other signers
• Call R the sum of the R_i points
• Each signer computes s_i = r_i + H(L,X_i,R,m)x_i
• The final signature is (R,s) where s is the sum of the s_i values
• Verification requires sG = R + H(L,X₁,R,m)X₁ + H(L,X₂,R,m)X₂ + …

Technically, BN has a precommit round, where the signers first reveal H(R_i) to each other, before revealing the R_i points themselves. This step is necessary to prove security under the DL assumption, but it can be avoided if we instead accept the OMDL assumption. This is also the distinction between two-round and three-round MuSig.

Update 2019-02-19: In light of this paper by Drijvers et al., we realize that the above paragraph is incorrect. It is insecure to simply skip the precommitment round in MuSig.

Furthermore, when an IAS is desired (where each signer has their own message), appendix A of our paper suggests using L = H((X₁,m₁),(X₂,m₂),…) instead, and s_i = r_i + H(L,R,i)x_i for signing (and analoguous for verification).

In any case, the resulting signature does not satisfy the normal Schnorr equation anymore, nor any other equation that can be written as a function of a combination of the public keys. In other words, we’ve lost the key aggregation property in order to gain security in the plain public-key model.

MuSig

This is where MuSig comes in. It recovers the key aggregation property without losing security:

• Call L = H(X₁,X₂,…)
• Call X the sum of all H(L,X_i)X_i
• Each signer chooses a random nonce r_i, and shares R_i = r_iG with the other signers
• Call R the sum of the R_i points
• Each signer computes s_i = r_i + H(X,R,m)H(L,X_i)x_i
• The final signature is (R,s) where s is the sum of the s_i values
• Verification again satisfies sG = R + H(X,R,m)X

That’s it! All we had to do was define X not as a simple sum of the individual public keys X_i, but as a sum of multiples of those keys, where the multiplication factor depends on a hash of all participating keys.

Acknowledgements

We’re very grateful to Yannick Seurin for his interest in reviewing MuSig’s security, writing its security proof, as well as coming up with the name.