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

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密钥与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曲线弱点中拯救出来（如果真的存在于"数学加密场景"后面

Answer 1

我将按顺序回答：

1. 如何检测Signature使用的曲线ecdsaSign=Signature.getInstance（"SHA256withECDSA"，"BC"）

你不能，因为公众&私钥应该包含参数，而不是算法。但是，基础库只支持某些曲线参数。在Bouncy Castle的情况下，这些是F（p）和F（2^m）曲线的那些。其中至少包括NIST和Brainpool曲线。

2. 如果sign-and-verify返回true，这是否意味着我给ECDSA的GOST密钥与ECDSA兼容

是的，你可以放心地假设。如果不是这样的话，那么验证就会出现严重问题。正如你现在可能理解的那样，这是因为C1=C2。

---

请注意，您不应该使用这样的密钥，尤其是当密钥也用于GOST算法本身时。不混淆价值观是一种很好的做法。您应该使用SHA-256的（最左边的）字节，而不是密钥值（如果有使用它）。使用基于密钥的密钥派生函数（KBKDF）会更好。