我正在尝试用python对字节数组进行签名,方法与在加密库中使用secp256k1 from NodeJS相同
这是NodeJS/Browser上的代码:
const secp256k1 = require('secp256k1')
var message = [2, 118, 145, 101, 166, 249, 149, 13, 2, 58, 65, 94, 230, 104, 184, 11, 185, 107, 92, 154, 226, 3, 93, 151, 189, 251, 68, 243, 86, 23, 90, 68, 255, 111, 3, 0, 0, 0, 0, 0, 0, 187, 226, 2, 0, 0, 0, 1, 0, 0, 0, 0, 0, 9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 4, 0, 84, 101, 115, 116, 105, 0, 0, 0, 0, 0, 0, 0];
var private_key_buffer = [122, 241, 114, 103, 51, 227, 157, 149, 221, 126, 157, 173, 31, 111, 43, 118, 208, 71, 123, 59, 96, 68, 57, 177, 53, 59, 151, 188, 36, 167, 40, 68]
const signature = secp256k1.sign(SHA3BUF(message), private_key_buffer)
这是我在python中的实现:
^{pr2}$但由于某些原因,我在javascript代码中得到的签名与python代码不同:
java script signature: [23, 54, 64, 151, 95, 33, 200, 66, 246, 166, 144, 182, 81, 179, 124, 223, 250, 50, 137, 169, 45, 181, 197, 74, 225, 207, 116, 125, 50, 241, 38, 52, 118, 215, 252, 94, 191, 154, 200, 195, 152, 73, 1, 197, 158, 24, 72, 177, 118, 39, 241, 82, 114, 107, 25, 106, 67, 205, 202, 4, 7, 57, 82, 237]
python script signature: [213, 69, 97, 237, 85, 226, 217, 201, 51, 14, 220, 92, 105, 59, 54, 92, 87, 88, 233, 147, 191, 15, 21, 86, 134, 202, 205, 223, 83, 134, 70, 39, 10, 19, 147, 20, 181, 180, 88, 103, 79, 55, 144, 98, 84, 2, 224, 127, 192, 200, 200, 250, 170, 129, 67, 99, 163, 72, 92, 253, 109, 108, 104, 206]
那么如何使python代码输出与JS代码相同的签名呢?在
对于RFC6979中描述的确定性ECDSA,哈希算法在两个地方使用:一个算法(
H1
)用于散列消息,另一个(H2
)用于确定k
-值。k
是签名算法中的一个参数,其作用在RFC6979, section 2.4或{a3}中描述。对于非确定性变量,k
是随机确定的,对于确定性变量,如RFC6979中所述。在RFC6979没有指定}必须不同,请参见RFC6979, section 3.6。然而,一个实现提供了分别定义两个哈希算法的可能性是有意义的。在
H1
和{Python的ECDSA实现通常允许应用两种不同的哈希算法。在第二个例子中显示之前,下面的变量(对应于发布的Python代码)应用了相同的哈希算法}:
H1 = H2 = SHA3-256
。在sign_deterministic
-方法中指定的哈希算法同时定义H1
和{签名是:
下一个变体使用
H1 = SHA3-256
来散列消息,使用H2 = SHA256
来确定k
。这可以通过将sign_deterministic
-方法替换为sign_digest_deterministic
-方法来实现,该方法允许使用H1
对消息进行单独的哈希处理。在sign_digest_deterministic
-方法中指定的哈希算法只定义H2
:签名是:
以下代码在功能上与发布的NodeJS代码相同:
并生成与第二种情况相同的签名,即显然是
H2 = SHA256
。我没有找到一种不费吹灰之力就把它改成SHA3-256
的方法。但是,根据文档,实现RFC6979的replace the default generator是可能的。这也应该改变H2
,但可能会更贵。总而言之:修复两个代码不兼容的最简单方法 如上面第2种情况所述更改Python代码,即使用},类似于Python代码。在
sign_digest_deterministic
-方法。然后用SHA3-256
对消息进行哈希处理,k
-生成用SHA256
进行。一个更昂贵的替代方案是实现一个自己的生成器,在NodeJS代码中使用SHA3-256
启用k
生成。当然,您也可以尝试为NodeJS代码找到另一个ECDSA库,它允许您分别定义H1
和{更新:
规范签名:如果} 是基点的顺序。如果在
(r,s)
是签名,那么(r, -s mod n) = (r, n - s)
也是valid signature。这里^{s > n/2
中使用-s mod n = n - s
部分而不是s
,则签名的结果是无歧义的,并且仅限于n/2
以下的区域。这称为规范签名,它与Bitcoin topic特别相关,也经常用于test vectors。在相关问题 更多 >
编程相关推荐