2

我一直在为以太坊交易管理器编写签名服务，我需要使用Google KMS Golang APIs签署以太坊交易。我将尝试在下面总结我面临的问题。

以太坊需要在 R 中使用紧凑型 RLP 编码的 65 字节 ECDSA 签名 || 小号 || V 格式。另一方面，Google KMS 的 ECDSA 签名具有额外的标头组件（R 长度、S 长度等）以及可变长度的 R 和 S 组件。这使得这些签名与以太坊交易签名不兼容。

解决此问题的一种方法是从从 Google KMS 获得的 ecdsa 签名中解析 R 和 S 字节，计算并将 V 字节添加到末尾，并使用此签名来获得签名的以太坊交易。像这样的东西：

var parsedSig struct{ R, S *big.Int }
_, err = asn1.Unmarshal(body, &parsedSig)
if err != nil {
    logger.WithError(err).Error("failed to parse signature bytes")
    return err
}

但是，由于以下一个或多个原因，这可能会失败：

  • 通过解析 R 和 S 分量并添加 V 分量来创建 65 字节长度的紧凑 ECDSA 签名可能和听起来一样不可信。上面提到的 R 和 S 组件对于标准 ECDSA 签名并不总是 32 字节长度，这意味着通过连接组件创建的 ECDSA 签名可能并不总是导致 64 字节。
  • 目前在以太坊中签名的交易是在 RLP 编码交易后从 Keccak-256 摘要哈希创建的，如下所示： 
    // from go-ethereum
func rlpHash(x interface{}) (h common.Hash) {
    hw := sha3.NewLegacyKeccak256()
    rlp.Encode(hw, x)
    hw.Sum(h[:0])
    return h
}
    Google KMS 中的非对称 ECDSA密钥签名不支持 Keccak-256 SHA3 消息摘要。将 SHA-256 摘要用于以太坊交易是否有效？IMO 这将失败，因为所有交易签名验证都发生在 RLP 编码的 Keccak 哈希上。
  • 在这一点上，在检查了函数的secp256k1 实现之后，我不太确定如何计算 ECDSA 签名的 V 分量secp256k1_ecdsa_sign_recoverable()。

我该如何解决上述问题，以便能够使用 Google KMS 的非对称椭圆曲线签名算法创建可验证的签名以太坊交易？

4

0 回答 0