引言
在本体技术视点 | ECDSA中的随机数重用会导致什么问题？中，我们强调了随机数重用的危害。熵不足是引起随机数重复的原因之一，但更多时候是由于不良工程实现引起的问题。Sony 的 PS3 事件如此，此次 Anyswap 被攻击的原因也是如此。那么，我们是否可以在工程实现中规避随机数重用这样一个问题呢？本次技术视点将接着上次的话题，和大家一起了解确定性 ECDSA 签名算法。
随机数的重要性
我们之前的内容屡次提到随机数的重要性。粗略地来看，无论对于签名算法和加密算法，随机数可以看作消息发送方引入的保护待发送消息隐私性等的因子，让攻击者无法从多个消息中推导出有效信息，从而保证无论是签名算法还是加密算法能达到它们所标称的安全特性。
图源网络
在 ECDSA 签名算法中，随机数的重要性也不言而喻：
首先，随机数不能泄漏，泄漏的随机数可以使攻击者从签名结果中推导出签名者私钥；
其次，同一签名者不同签名时随机数不能重用，否则也可以使攻击者从签名结果中推导出签名者私钥；
最后，不同签名者之间也不能重用随机数，否则其中任意一个签名者都能推导出其它签名者的私钥。
确定性ECDSA签名算法
在现代密码学应用和区块链实践开发中，产生随机数的熵一般都足够，主要问题都是由于不良实现引起。正因为看到这样一个问题，IETF 在2013年针对 ECDSA 算法，发布了一个确定性签名算法版本，指导如何产生随机数，以规避在工程实现中可能产生的随机数问题。这就是我们在之前技术视点中提到的 RFC 6979。
在讲述确定性 ECDA 签名算法前，我们先简单介绍一个密码学原语：消息认证码（Message Authentication Code， MAC）。我们知道数字签名是非对称密码体制中用来保证消息完整性（消息认证）和不可抵赖性（实体认证）等的工具，而消息认证码就是对称密码体制中用来保证消息完整性的工具。MAC 的基本思想是通信双方 Alice 和 Blob 共享一个密钥，消息发送方 Alice 利用私钥对消息生成消息认证码，并将其和消息一起发送给接收方 Bob。Bob 收到后，利用其手中的密钥根据消息重新计算消息认证码并和 Alice 发送过来的消息认证码进行比对，匹配成功的话则认为消息在传递过程中没有被篡改。
我们在上述的描述中省略了一些实现过程中的转换，比如数值到字符串的转换等。在实现中，RFC 6979也提到了一些变种，比如利用额外的私密数据代替私钥，在上述第三步中引入额外的数据（比如某个单调递增的量）来使得即使同一消息的签名结果也不同。
结语
确定性 ECDSA 算法是规避随机数重用的方法，Bitcoin 等的实现中也采用了确定性 ECDSA 算法。但确定性 ECDSA 算法也可能遭受故障分析等侧信道分析攻击，在 HMAC 私钥计算中引入单调递增的量等来使得即使同一消息的签名结果也不同的作法是缓解这种攻击等方法。在 Anyswap 中，由于采用了 Gennaro 和 Goldfeder 在2020年提出的门限 ECDSA 方法，不太适用 RFC 6979。但我们看到有一些基于多方安全计算的伪随机数生成器（PRG）和伪随机算法（PRF）等出现，这可能适用于门限 ECDSA。有理由相信，我们会看到更多更有性能的算法出现在区块链中，保证区块链的安全。
