MuSig : 比特币可用的Schnorr签名方案 - 区块链前沿 - BitMere

在2018年，区块链协议公司Blockstream的密码学家Gregory Maxwell、Pieter Wuille等人提出了一种名为MuSig的Schnorr签名方案，理论上可替代当前比特币的ECDSA签名算法，而在今日，Blockstream已经把MuSig从一篇学术论文，转变成了可用的代码，并进行了开源。
对此，来自Blockstream的数学家Andrew Poelstra向社区分享了这一技术的进展，以下为其分享内容的译文：

(图片来自：Blockstream)
当前，比特币和其他区块链普遍采用的是ECDSA签名验证算法。这显然是中本聪在2008年根据当时的环境所做出的技术决定。然而，ECDSA签名存在一些严重的技术限制。特别是，多重签名和门限签名很难与ECDSA一起生成。ECDSA签名具有复杂的代数结构，使其不灵活且难以使用，迫使开发人员在跨链原子交换或闪电网络等应用中使用比特币脚本，而这可通过更灵活的签名方案，更紧凑、更私密地实现这些应用。
在2018年，区块链协议公司Blockstream的密码学家Gregory Maxwell、Pieter Wuille等人提出了一种名为MuSig的Schnorr签名方案，理论上可替代当前比特币的ECDSA签名算法，这种多重签名方案提供了可证明的安全性，甚至可防止恶意签名者的合谋子集，并生成与普通单签名者Schnorr签名不可区分的签名（提高隐私性）。
经过近1年的发展，Blockstream已经把MuSig从一篇学术论文，转变成了可用的代码，本周，其开发人员会把代码合并到secp256k1-zkp（secp256k1的一个fork），此外，Blockstream还把保密交易（CT）技术扩展到其Elements和Liquid侧链产品。
需要注意的是，目前比特币core代码库依然使用的是secp256k1，因此目前MuSig并没有被应用到比特币，但这也是Blockstream所期待的目标。
而假设比特币启用这一签名方案，将使得闪电网络可在无脚本脚本（scriptless script）中应用。
MuSig签名方案的优势
根据Blockstream官方发布的说明，应用MuSig签名方案将重点会有以下两大优势：

无论签名者设置如何，验证者都会看到相同的短的、常量大小的签名。在区块链系统中，验证效率是最重要的考虑因素，用签名者细节来给验证者增加负担，是不合理的，除非是安全需要，否则是无必要的。此外，MuSig签名方案能够提高隐私性，因为它们隐藏了确切的签名者策略。

为普通公钥模型提供可证安全性。这意味着签名者可完全灵活地使用普通的密钥对进行多重签名，而不需要提供任何关于这些密钥产生或控制的特定方式的额外信息。有关密钥生成的信息，可能很难在比特币的环境中提供，因为各个签名者具有不同的和限制性的密钥管理策略。此外，对密钥生成细节的依赖性，可能会与Taproot（一种提议的比特币扩展方案）产生不良的交互作用，其中公共签名密钥可能会有额外的隐形语义。

误区和安全API开发
与所有多重签名协议的数学描述一样，发布后的MuSig，假定参与者在整个签名过程中都可访问内存，而签名过程是持久的、易于更新的，并且攻击者不能“重置”到以前的状态。它还假设签名者可访问随机性来源，这些来源与uniform不可区分。不幸的是，现实世界并没有那么简单，Blockstream花了大量的精力设计了一个API，它可以在各种各样的场景中使用，而不存在因未声明的假设而导致密钥丢失的可能。
就像Schnorr签名或者ECDSA，MuSig签名方案在其结构中使用了一个秘密的“nonce”，其必须统一随机生成。任何偏离统一标准的行为，即使只是一点点，也可能导致密钥丢失和资金被盗。
Blockstream的主要设计目标，是创建一个安全的防误用API，即使是在受限的环境中，也不会鼓励危险的使用模式。
Uniform随机性
对于单个签名，实现统一随机nonce的标准方法很简单：取一些机密数据和要签名的消息，通过加密哈希函数传递这些数据，得到一个统一随机值，该值对于每个要签名的消息而言都是独立的。
然而，有了多重签名，这个简单而健壮的解决方案就成了一种负担。恶意签名者可能会在同一条消息上请求两个多重签名，从而在第二次迭代中调整自己对签名的贡献。如果第一个签名者通过在消息旁边哈希一个秘密来选择他的nonce，那么他最终将在两个非常不同的签名中使用相同的nonce（本质上是导致PS3被黑客攻击的相同失败模式。）不幸的是，与单个签名者的情况不同，没有简单的解决方案，因为单个签名者必须在知道要生成的签名的所有细节之前选择它们的nonce。
解决这个问题的一个传统方法，是使用硬件随机数生成器，这种方法在散列法（ hashing）流行之前就已被使用了。不幸的是，这类方案都是昂贵的，会受到环境偏见或其他外部影响，最重要的是，我们没有办法验证它们是否正确运行。
关于验证这一点，有一些创造性的解决方案，Blockstream将在以后的文章中探讨。目前，其选择是要求API用户为每个签名会话提供唯一的“会话ID”。nonce是通过哈希签名者的秘密、签名者集、要签名的消息，以及这一会话的唯一输入而产生的。可访问随机数生成器的用户，可以使用它来生成会话ID，而可问持久内存的用户，只需使用计数器即可。
目前开发人员期望能很快生产出一个真正强大的解决方案。
关于重放攻击（Replay Attack）
即使有一个可靠的随机性来源，仍有可能从多重签名的参与者那里提取私钥（如果在整个过程中，可能从一个点重放签名协议的话），这种类型的攻击被称为“重放攻击”，可针对在可重启的虚拟机内运行的签名者，以及支持间断签名及从可序列化状态恢复的虚拟机发动攻击。它甚至可能在没有活动攻击者的情况下意外发生，例如运行从同一状态克隆的两个虚拟机，或者在不同步的分布式数据库上执行代码。
具体来说，如果一个签名者贡献了一个多重签名，并且签名过程在选择了他的nonce之后的某一点，通过重启的方式，则可修改其他签名者对签名的贡献。
这些类型的攻击不会以单个签名出现，因为它们是在一个步骤中生成的，没有中间状态可从中重新启动。这些额外的挑战，对于多轮加密协议来说是独一无二的。
如果不去研究新的机制，目前的MuSig签名方案就无法保护在虚拟机中进行签名的用户。同样，这一限制在Blockstream的开发者看来是可消除的，目前他们正在积极研究解决方案。
结论，以及未来的工作
所有上述讨论都隐含着这样一个观点：**即相比单方协议，多方协议会面临新的、实质上更困难的挑战。**就数学复杂性而言，MuSig要比Bulletproofs（防弹证明）要简单得多。但在实现复杂性方面，MuSig已经付出了更多的努力，并且需要在抗脆性和API灵活性之间进行更多的权衡。
这篇文章只描述了多重签名部分，在未来的文章中，开发者还将描述门限签名，这是一个相关的概念，其中n个签名者的任何子集，只要数量足够，就能够生成签名，而不需要整个签名组的贡献。
在以后的文章中，我们还将讨论一些使非随机性更安全和更可验证的技术。特别是，通过使用一种称为签订合约（sign-to-contract）的技术，主机可以从不可信的硬件钱包的随机数生成器中消除任何偏差的可能性。
更进一步的是，通过利用零知识证明的能力，应该可消除偏随机性（biased randomness）和重放攻击所带来的风险，消除对持久内存的需求，并将MuSig协议从3轮通信减少到2轮。
读者可查看MuSig在Github上的代码（https://github.com/ElementsProject/secp256k1-zkp/tree/secp256k1-zkp/src/modules/musig），并对其发布评论或提出改进。