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

Question

根据 wiki ECDSA 中的公钥是私钥(随机数)与椭圆曲线 C 上的某个基点 G 的乘积。并且我们在签名和验证中也使用了 C。

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

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

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

2. 如果 sign and verify 返回 true，是否意味着我提供给 ECDSA 的 GOST key 与 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 key 生成曲线和 SHA256withECDSA 的内部曲线可能不相等，这就是我问这个问题的原因。

更新

回答

May I use some G1 and C1 for public key generation and other curve C2 for signing and verification?

不，C1 必须等于 C2。

检测 BC 曲线是可能的——我查看了 BC 的 SignatureSpi 源，看到从 key 中获取的曲线参数。并且发现的C2等于已知的C1。换句话说，不是 SHA256withECDSA 而是 prKey.getAlgorithm() 决定。

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

请注意，KBKDF 不会从 ECDSA 中的 GOST 曲线弱点中拯救(如果它真的存在于“math-crypto-scenes”的背后

Answer 1

我会按顺序回答:

1. How detect curve used by Signature ecdsaSign = Signature.getInstance("SHA256withECDSA", "BC");

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

2. If sign and verify returns true, does it mean that GOST keys which I gave to ECDSA are compatible with ECDSA?

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

---

请注意，您不应像这样使用 key ，尤其是当 key 也用于 GOST 算法本身时。最好不要混合值。您应该改为使用 SHA-256 的(最左边)字节而不是 key 值(如果您有使用它)。使用基于 key 的 key 派生函数 (KBKDF) 会更好。