ウィキによると、ECDSA の公開鍵は、楕円曲線 C 上のある基点 G に秘密鍵 (乱数) を乗算したものです。また、署名と検証の両方で C を使用しています。
一部の G1 と C1 を公開鍵の生成に使用し、別の曲線 C2 を署名と検証に使用してもよいですか?
奇妙に聞こえるかもしれませんが、私の実際の目標は、ECDSA で GOST 秘密鍵を使用することです(既に所有しており、使用する必要があります)。したがって、GOST public は特別な C1、G1 から生成される可能性があり、JavaSHA256withECDSA
はおそらく他の曲線を使用します。
- で使用される曲線をどのように検出し
Signature ecdsaSign = Signature.getInstance("SHA256withECDSA", "BC");
ますか? sign と 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 ソースを調べたところ、キーから取得された曲線パラメーターが表示されました。そして、既知の C1 と等しい C2 を発見しました。つまり、そうではなくSHA256withECDSA
、prKey.getAlgorithm()
決める。
しかし!!キーの互換性は、それを安全に使用できるという意味ではありません。GOST 曲線には、いくつかの ECDSA ステップで影響を与える可能性のある特別な不変条件があります。これは興味深いですが、非常に難しい質問です。ECDSA に GOST 曲線の弱点はありますか? ということで、「互換性はありますが、使用前に数学のスタッフによく確認してください」というのが答えです。
KBKDF は ECDSA の GOST 曲線の弱点から救われないことに注意してください ( 「数学暗号シーン」の背後に実際に存在する場合)。