公钥生成和签名计算的椭圆曲线是否相同？

Question

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

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

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

1. 如何检测Signature ecdsaSign = Signature.getInstance("SHA256withECDSA", "BC");使用的曲线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内部曲线可能不相等，这就是我问这个问题的原因。

UPDATE

回答

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

不，C1必须等于C2。

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

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

注意，KBKDF不能保存ECDSA中的GOST曲线弱点（如果它真的存在于“math-crypto-scenes”之后）

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）会更好。