⚠️原文：Schnorr Applications: MuSig

⚠️写在前面：本文属搬运博客，自己留存学习。

1 什么是多签名？

多签名 是指：一组签名密钥 $(X_1,X_2,...,X_n)$ 共同生成一条消息的签名。

任何正常签名方案 —— 如 Schnorr 或 ECDSA —— 的多签名方案，最简单的方法是将每个签名者对给定消息的单个签名连接起来：$s=(s_1,s_2,...,s_n)$ 。

个人理解：默认的 Schnorr 或 ECDSA 是单签名方案，但它们也可以有多签名版本。最简单的方式，就是将各个单签名连接起来，构成一个多签名。

这个方案已在比特币中通过操作 OP_CHECKMULTISIG —— 简称 OP_CMS —— 得到支持。实际上，OP_CMS 支持更多的操作，你可以创建一个由 m-of-n 参与者控制的地址，其中 m ≤ n，但我们今天只考虑 n-of-n 的情况。

什么是 m-of-n 参与者？答：意思是，至少需要 n 个参与者中的 m 个人同意，才能生成一个有效的签名。当 m=1 时，它等同于传统的单签名方案，即只需要一个人同意即可生成签名。

虽然 OP_CMS 是一个正确的多签名方案，但它有一些严重的缺点。在这种方案中，n-of-n 多签名将是常规签名的 n 倍 大小，因为它需要在链上放置 n 个签名和公钥对。同样，这比验证单个签名需要更长的时间。最后，它没有隐私功能，因为所有参与者都是公开的，即所有 n 个密钥都必须用于验证。

为什么需要在链上放置 n 个签名和公钥对？答：因为在验证签名的时候，我们需要使用相应的签名和公钥。由于在 OP_CMS 方案中，一个多签名是由 n 个签名拼接来的，因此我们在验证时需要这 n 个签名和它们各自对应的公钥。

MuSig 旨在解决这些问题，它是一个 Schnorr 多签名方案。无论签字方的数量多少，它都能产生一个与普通 Schnorr 签名无法区分的签名。因此，MuSig 签名的验证与普通 Schnorr 签名完全相同。此外，它支持 密钥聚合，因此单个签名密钥可以保持私密。

与 OP_CMS 相比，MuSig 降低了存储负担、减少了验证时间、保护了密钥隐私😇

具体来说，假设有 n 个签名者 $X_1,X_2,...,X_n$ 和一条消息 $m$，他们希望共同签署这条消息。通过使用 MuSig，他们可以生成一个单一的 Schnorr 签名 $(R,s)$ 。

这将使用 聚合密钥 $X=agg(X_1,X_2,...,X_n)$ 对 $m$ 进行有效签名，这样在任何公共空间 —— 如区块链 —— 中，这 n 个签名者们可以假装自己只是一位拥有密钥 $X$ 的签名者。简而言之，我们可以使得多签名输出和标准输出没有区别。

2 朴素 Schnorr 多签名

针对签名者 $i$，我们对其所使用的变量进行说明：

• 私钥：$x_i$
• 公钥：$X_i=x_i\ast G$
• 一次性私钥：$k_i$
• 部分签名：$R_i=k_i\ast G$
• 部分签名：$s_i=k_i+H(X,R,m)\ast x_i$

为什么叫作一次性私钥？答：签名者 $i$ 每次签名都会重新生成一个随机值 $k_i$，对 $k_i$ 是用完即弃，与 $x_i$ 这种长期性私钥应该区分开来。

假设有 $n$ 个签名者。

朴素 Schnorr 多签名让每个签名者分享自己的公钥 $X_i$，计算并定义聚合密钥为：

$$X=X_1+X_2+...+X_n$$

让每个签名者生成并分享自己的部分签名 $R_i$，计算并定义部分聚合签名为：

$$R=R_1+R_2+...+R_n$$

为什么 $R_i$ 被称为 部分签名， $R$ 被称为 部分聚合签名？答：因为一个完整的签名是 $(R,s)$，所以单独的 $R$ 或 $s$ 只能算作部分签名或者部分聚合签名。

获得部分聚合签名 $R$ 后，每个签名者可以自行计算他们的部分签名 $s_i$：

$$s_i=k_i+H(X,R,m)\ast x_i$$

为了让 $s_i$ 们可以相加，朴素 Schnorr 多签名 将 Schnorr 签名 中的 $H(X,R_i,m)$ 改为了 $H(X,R,m)$。

然后再分享自己的部分签名 $s_i$，计算并定义部分聚合签名为：

$$\begin{array}{rl}s& =s_1+s_2+...+s_n\\ & =(k_1+...+k_n)+H(X,R,m)\ast (x_1+...+x_n)\\ & =k+H(X,R,m)\ast x\end{array}$$

最终的朴素 Schnorr 多签名为 $(R,s)$，涉及以下变量：

• 聚合私钥：$x$
• 聚合公钥：$X$
• 聚合一次性私钥：$k$
• 聚合部分签名：$R$
• 聚合部分签名：$s$

验证者的验证等式为：

$$s\ast G\stackrel{?}{=}R+H(R,M)\ast X$$

可以看出，上述方案不仅是一个 多签名方案，还是一个 聚合签名方案，因为它允许将多个签名合并为一个签名，隐藏掉了原始的单个签名的信息。遗憾的是，该方案容易受到所谓的 恶意密钥攻击 或称 流氓密钥攻击。

英文是 Rogue Key Attack

3 恶意密钥攻击

假设我的公钥是 $X_1$ 。

我可以撒谎，将一个 $X_1^{\prime }=X_1-X_2-...-X_n$ 值传给其他签名者，并声称这就是我的公钥。这将导致聚合公钥 $X$ 变为 $X=X_1^{\prime }+X_2+...+X_n=X_1$。又因为我是公钥 $X_1$ 的所有者，所以我知道 $X_1$ 对应的私钥。由此一来，我可以单方面将资金发送到任何我想要的地方，而无需任何合作。

首先，因为公钥都是公开的，所以我可以获取到所有其他签名者的公钥。接着，我令虚假公钥的值为 $X_1-X_2-...-X_n$，以此使聚合公钥 $X$ 退化为我的公钥 $X_1$ 。最后，我便可以为所欲为😈

如果你要求我证明：我对声称属于我的公钥拥有私钥，这将阻止我的恶意密钥攻击，但我还可以对随机数值 $R_i$ 执行相同的攻击，以控制聚合一次性私钥 $k$ 。

原文中的 nonce 值是什么意思？答：nonce 是 number once 的缩写，在密码学中 nonce 是一个只被使用一次的任意或非重复的随机数值。

然后，我会在接收完所有其他签名者的部分签名 $s_i$ 之后，计算出聚合签名 $s=k+H(X,R,m)\ast x$，这将允许我计算出 $x$，再次让我能够不合作地将所有资金发送到任何地方。

刚才已经获取到了 $k$ 值，$s$ 和 $H(X,R,m)$ 又是已知的，因此可以倒推出 $x$ 的值。

4 改进方案

为了修复上述方案，我们需要确保聚合随机数值 $R$ 和聚合公钥 $X$ 能够抵御恶意密钥攻击。

具体来说，我们要求每个签名者广播自己的随机数 $R_i$ 的哈希值 $t_i=H(R_i)$ —— 而非 $R_i$ 本身 —— 并且只有在看到所有其他签名者的 $t_i$ 之后才揭示自己的随机数 $R_i$ 。

这里说的其实就是一个哈希承诺的过程，请自行补课密码学承诺😇

这种方案能够缓解对随机数 $R_i$ 的攻击，但对聚合签名公钥 $X$ 来说却不切实际。因为公钥通常是公开的并且可以被重复使用。

上述方案相当于是把 $R_i$ 藏起来，但 $X_i$ 作为公钥是需要被公开的，因此不切实际。

因此，我们可以尝试改变我们的聚合公钥 $X$，使其通过所有签名公钥 $X_i$ 的哈希值来计算。

具体来说，令 $L$ 为所有公钥的集合 $(X_1,X_2,...,X_n)$ 的某种编码，然后让：

$$a_i=H(L||X_i)$$$$X=a_1\ast X_1+a_2\ast X_2+...+a_n\ast X_n$$

其中 $H$ 表示哈希函数。

终于看到论文中使用的方法了，喜极而泣😈

这样就很难从 $(X_1,X_2,...,X_n)$ 中计算出一个 $X_1^{\prime }$ 使得 $X=X_1$ 了。

然而，这样的修改会使聚合私钥 $x=x_1+...+x_n$ 的值不再是聚合公钥 $X$ 对应的私钥的值。幸运的是，有一个简单的调整可以修复这个问题：

$$s_i=k_i+H(X,R,m)\ast a_i\ast x_i$$

个人理解：聚合私钥 $x$ 本质上就是聚合公钥 $X$ 的私钥，需要满足 $x\ast G=X$ 这一关系。这里 $X_i$ 乘以 $a_i$ 这一权重后导致 $X$ 发生了改变，那么 $x_i$ 也需要乘以相应的权重，以保证 $x$ 仍然是 $X$ 的私钥。

这样我们就恢复了我们的聚合签名：

$$\begin{array}{rl}s& =s_1+s_2+...+s_n\\ & =(k_1+...+k_n)+H(X,R,m)\ast (a_1\ast x_1+...+a_n\ast x_n)\\ & =k+H(X,R,m)\ast x\end{array}$$

回顾一下，MuSig 签名过程包括三个阶段：

1. 所有签名者发送承诺 $t_i$；
2. 所有签名者揭示随机数 $R_i$，并且所有签名者验证 $t_i=H(R_i)$；
3. 所有签名者计算并发送他们的部分签名 $s_i$；

最后，任何所有签名者都可以计算并使用普通 Schnorr 签名 $(R,s)$ 。

什么是承诺？答：承诺全称密码学承诺，是一个密码学概念，主要用于防止发送者撒谎。

5 未来展望

这是本文中证明安全的 MuSig 提案，但许多人对需要 3 个往返通信的要求不满意，并且已经有很多工作致力于消除一个交互性的回合，以制作一个只有 2 个回合的 MuSig 版本。参见 Jonas Nick 的这篇博客文章，了解为什么将 3 个回合协议缩短为 2 个回合协议的各种捷径是不安全的。