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

Should elliptic curve for public key generation and signature computation be the same?

根据wiki public ECDSA 中的密钥是私钥(随机数)乘以椭圆曲线 C 上的某个基点 G。而且我们在签名和签名中都使用了 C确认。

我可以使用一些 G1 和 C1 用于 public 密钥生成和其他曲线 C2 用于签名和验证吗?

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

  1. 如何检测Signature ecdsaSign = Signature.getInstance("SHA256withECDSA", "BC");使用的曲线?
  2. 如果签名并验证returns为真,是否意味着我给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 的内部曲线可能不相等,这就是我问这个问题的原因。

更新

回答

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

不,C1 必须等于 C2。

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

但是!!密钥的兼容性并不意味着使用它是安全的。 GOST 曲线具有特殊的不变量,可能会影响某些 ECDSA 步骤 - 这是一个有趣但非常困难的问题 - ECDSA 中是否存在 GOST 曲线的弱点。所以,答案是 "compatible but check carefully math staff before using"

请注意,KBKDF 不会从 ECDSA 中的 GOST 曲线弱点中拯救(如果 确实 存在于 "math-crypto-scenes" 之后

我按顺序回答:

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

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

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

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


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