ECDSA确定性签名
- asecuritysite
- 发布于 1天前
- 阅读 17
本文介绍了ECDSA签名中的确定性签名方法，传统的ECDSA签名在生成签名时依赖随机数nonce，这可能导致安全问题和测试困难。确定性签名通过RFC 6979标准，使用消息和私钥的哈希来生成nonce，从而确保相同的消息和私钥每次都生成相同的签名。OpenSSL 3.6实现了这一标准，并提供了相应的命令行选项。
使用 ECDSA 的确定性签名
当开发者使用 ECDSA 签名时，需要注意，因为每个签名的生成都涉及到随机数。如果这个值不是完全随机的或者重复了，会严重降低签名的整体安全性。因此，这种方法创建了一种非确定性的方法，相同的信息和私钥每次都会产生不同的签名。这可能会给测试签名过程带来困难。
使用确定性方法，我们不改变 nonce 值，并且对于相同的消息和私钥，产生相同的签名。这使得测试更容易，并且不依赖于随机 nonce 的生成。除此之外，签名不太容易受到侧信道攻击，因为它不必集成随机化过程。在随机化机会较弱的情况下，例如在 IoT 设备中，它特别有用。
使用 ECDSA，我们为每个签名生成一个随机 nonce (k)，并且对于相同的消息和相同的私钥，签名会发生变化。我们可以为一系列曲线生成一个 ECC 密钥对，然后为消息生成一个 ECDSA 签名 (r,s)。我们首先获取消息的 SHA-256 哈希值，然后使用私钥对其进行签名，然后使用相关的公钥进行验证。
对于确定性签名，对于相同的消息和私钥，我们获得相同的签名。这在 RFC 6979 中定义 [ here]，并在 OpenSSL 3.6 中实现。
在这种情况下，我们将创建一个确定性签名，我们不使用随机 nonce 来创建签名，并且相同的输入文本和私钥将为我们提供相同的签名。有了这个，我们根据消息和私钥的哈希值生成 nonce 值 (k)，它基于 RFC 6979：
我们可以创建一个私钥，然后使用导出公钥 [ here]:
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:secp112r1 -out ec_priv.pem
openssl pkey -in ec_priv.pem -pubout -out ec_pub.pem然后我们可以使用确定性签名 [ here]:
echo - n Qwerty123 | openssl dgst - sha256 -sign ec_priv.pem
-sigopt nonce -type:1 -out sig1.der
echo - n Qwerty123 | openssl dgst - sha256 -sign ec_priv.pem
-sigopt nonce -type:1 -out sig2.der在 OpenSSL 3.6 中，我们使用签名的“ -sigopt nonce -type:1”选项来定义确定性签名。最后，我们可以使用公钥进行验证 [ here]:
echo -n Qwerty123 | openssl dgst -sha256
-verify ec_pub.pem -signature sig1.der
echo -n Qwerty123 | openssl dgst -sha256
-verify ec_pub.pem -signature sig2.der消息“Qwerty123”的示例运行是 [ here]:
Message to sign "Qwerty123" // 要签名的消息 "Qwerty123"
Private key: // 私钥
0:d=0 hl=3 l= 135 cons: SEQUENCE
3:d=1 hl=2 l= 1 prim: INTEGER :00
6:d=1 hl=2 l= 19 cons: SEQUENCE
8:d=2 hl=2 l= 7 prim: OBJECT :id-ecPublicKey
17:d=2 hl=2 l= 8 prim: OBJECT :prime256v1
27:d=1 hl=2 l= 109 prim: OCTET STRING [HEX DUMP]:306B0201010420A1813CDE99EF6EE729A41A055FD328F5C8B20EC8E3B3E8C5862E6A91ED35046AA1440342000456501DEBC8EC2A84E6A28F884CAF46025526829327DB189914F24746C4C6CA660BA7CB29AECB0447FCC0099E7DD13C92324BAF4502CFBE57DB4D27D0566F5980
Public key: // 公钥
0:d=0 hl=2 l= 89 cons: SEQUENCE
2:d=1 hl=2 l= 19 cons: SEQUENCE
4:d=2 hl=2 l= 7 prim: OBJECT :id-ecPublicKey
13:d=2 hl=2 l= 8 prim: OBJECT :prime256v1
23:d=1 hl=2 l= 66 prim: BIT STRING
"Testing signature 1" // 测试签名 1
Verified OK // 验证通过
"Testing signature 2" // 测试签名 2
Verified OK // 验证通过
"Signature 1:" // 签名1
0:d=0 hl=2 l= 70 cons: SEQUENCE
2:d=1 hl=2 l= 33 prim: INTEGER :B7530281F779FF63B6511CA95C0D3723706CD02B08F9B889DDE1B61D90052E4A
37:d=1 hl=2 l= 33 prim: INTEGER :F9A6D97A8A8EF8FD596CA734A0E119BBF72A57617926104978DBDAFE52B34749
"Signature 2:" // 签名2
0:d=0 hl=2 l= 70 cons: SEQUENCE
2:d=1 hl=2 l= 33 prim: INTEGER :B7530281F779FF63B6511CA95C0D3723706CD02B08F9B889DDE1B61D90052E4A
37:d=1 hl=2 l= 33 prim: INTEGER :F9A6D97A8A8EF8FD596CA734A0E119BBF72A57617926104978DBDAFE52B34749我们可以看到，对于相同的消息和私钥，签名是相同的。
- 原文链接： medium.com/asecuritysite...
- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
