公钥生成和签名计算的椭圆曲线应该相同吗？

Posted 2023-03-09

【中文标题】公钥生成和签名计算的椭圆曲线应该相同吗？

【英文标题】：Should elliptic curve for public key generation and signature computation be the same?

【发布时间】：2015-06-24 04:03:39

【问题描述】：

根据ECDSA中的wiki公钥是私钥（随机数）乘以椭圆曲线C上的某个基点G。而且我们在签名和验证中都使用了C。

我可以使用一些 G1 和 C1 生成公钥，使用其他曲线 C2 进行签名和验证吗？

我知道这听起来很奇怪，但我的实际目标是在 ECDSA 中使用 GOST 私钥（我已经拥有它们并且必须使用它们）。因此，GOST public 可能是由特殊的 C1、G1 和 Java 的SHA256withECDSA 可能使用其他知道的曲线生成的。

如何检测Signature ecdsaSign = Signature.getInstance("SHA256withECDSA", "BC");使用的曲线？

如果签名和验证返回 true，是否意味着我提供给 ECDSA 的 GOST 密钥与 ECDSA 兼容？

  Signature ecdsaSign = Signature.getInstance("SHA256withECDSA", "BC");
  ecdsaSign.initSign(privateKeyGOST);
  ecdsaSign.update("aaaa".getBytes("UTF-8"));
  byte[] signature = ecdsaSign.sign();

  Signature ecdsaVerify = Signature.getInstance("SHA256withECDSA", "BC");
  ecdsaVerify.initVerify(publicKeyGOST);
  ecdsaVerify.update("aaaa".getBytes("UTF-8"));
  System.out.println();
  System.out.println(ecdsaVerify.verify(signature));  //TRUE

请注意，GOST 密钥生成曲线和 SHA256withECDSA 的内部曲线可能不相等，这就是我问这个问题的原因。

更新

回答

我可以使用一些 G1 和 C1 生成公钥，使用其他曲线 C2 进行签名和验证吗？

不，C1 必须等于 C2。

可以检测 BC 曲线 - 我查看了 BC 的 SignatureSpi 源，并看到曲线参数取自密钥。并发现 C2 等于已知 C1。换句话说，不是SHA256withECDSA 而是prKey.getAlgorithm() 决定。

但是！！密钥的兼容性并不意味着使用它是安全的。 GOST 曲线具有特殊的不变量，可能会影响某些 ECDSA 步骤 - 这是一个有趣但非常困难的问题 - ECDSA 中是否存在 GOST 曲线的任何弱点。所以，答案是“兼容但在使用前仔细检查数学人员”

请注意，KBKDF 不会从 ECDSA 中的 GOST 曲线弱点中解救出来（如果它真的存在于“数学-加密-场景”之后

【参考方案1】：

我会按顺序回答：

如何检测 Signature ecdsaSign 使用的曲线 = Signature.getInstance("SHA256withECDSA", "BC");

你不能因为公钥和私钥应该包含参数，而不是算法。但是，底层库仅支持某些曲线参数。在 Bouncy Castle 的情况下，这些是 F(p) 和 F(2^m) 曲线。这些至少包括 NIST 和 Brainpool 曲线。

如果签名和验证返回 true，是否意味着我提供给 ECDSA 的 GOST 密钥与 ECDSA 兼容？

是的，您可以放心地假设。如果不是这种情况，那么验证就会出现严重错误。正如您现在可能理解的那样，这是因为 C1 = C2。

---

请注意，您不应使用这样的密钥，特别是如果密钥也用于 GOST 算法本身。不混合值是一种很好的做法。您应该使用 SHA-256 的（最左边的）字节而不是密钥值（如果您 有 可以使用它）。使用基于密钥的密钥派生函数 (KBKDF) 会更好。

【讨论】：

可以使用曲线。总的来说，我同意你的看法。然而，在 ECDSA 的使用中存在 GOST 曲线弱化的可能性，KBKDF 不会从中拯救，因为问题不在 key 上，而是在 GOST 曲线上。查看更新。

这会被认为是一种“量子安全”的加密方法吗？