問題タブ [ecdsa]

ウィキによると、ECDSA の公開鍵は、楕円曲線 C 上のある基点 G に秘密鍵 (乱数) を乗算したものです。また、署名と検証の両方で C を使用しています。

一部の G1 と C1 を公開鍵の生成に使用し、別の曲線 C2 を署名と検証に使用してもよいですか?

奇妙に聞こえるかもしれませんが、私の実際の目標は、ECDSA で GOST 秘密鍵を使用することです(既に所有しており、使用する必要があります)。したがって、GOST public は特別な C1、G1 から生成される可能性があり、JavaSHA256withECDSAはおそらく他の曲線を使用します。

1. で使用される曲線をどのように検出しSignature ecdsaSign = Signature.getInstance("SHA256withECDSA", "BC");ますか?

2. sign と verify が true を返した場合、私が ECDSA に与えた GOST 鍵は ECDSA と互換性があるということですか?

   /li>

GOST キー生成の曲線と内部曲線がSHA256withECDSA 等しくない可能性があることに注意してください。そのため、この質問をしています。

アップデート

に答えます

一部の G1 と C1 を公開鍵の生成に使用し、別の曲線 C2 を署名と検証に使用してもよいですか?

いいえ、C1 は C2 と等しくなければなりません。

BC 曲線を検出することは可能です。BC の SignatureSpi ソースを調べたところ、キーから取得された曲線パラメーターが表示されました。そして、既知の C1 と等しい C2 を発見しました。つまり、そうではなくSHA256withECDSA、prKey.getAlgorithm()決める。

しかし！！キーの互換性は、それを安全に使用できるという意味ではありません。GOST 曲線には、いくつかの ECDSA ステップで影響を与える可能性のある特別な不変条件があります。これは興味深いですが、非常に難しい質問です。ECDSA に GOST 曲線の弱点はありますか? ということで、「互換性はありますが、使用前に数学のスタッフによく確認してください」というのが答えです。

KBKDF は ECDSA の GOST 曲線の弱点から救われないことに注意してください ( 「数学暗号シーン」の背後に実際に存在する場合)。

NIST SP 800-56A のセクション 5.8.1 で説明されているキー派生関数を使用して、キー マテリアルを派生させる必要があるタスクがあります。私は暗号化の専門家ではないので、質問が素朴でしたらすみません。これまでに行ったことは次のとおりです。

1. 相手の公開鍵と自分の秘密鍵を持っている

2. ここで、C# (.NET 4) ECDiffieHellmanCng クラスを使用して、ECDH 1.3.132.1.12 を使用して共有シークレットを生成しようとします。

   /li>

最後にこれを行います：

他のパラメータ アルゴリズム ID、パーティ U 情報、パーティ V 情報はどこでどのように設定すればよいですか?

編集 私は、Bouncy Castle のような他のライブラリを使用することにオープンです (.NET から呼び出すことができる場合)。

Java/Android と .Net 環境で作成された ATEC108A チップで署名を検証する必要があります。(SunEC と AndroidOpenSSL を使用)

署名は BCrypt を使用して .Net で作成され、キーも BCrypt を使用して作成され、Microsoft キー ストアに保存されます。署名と公開鍵を AT チップに送信して検証できますが、Android では機能しません。

キー/署名プロセス:

1. 公開鍵は、SHA256-ECDSA の識別子と曲線 prime256v1 を含む x.509 鍵形式で BCrypt からエクスポートされ、次のようになります。

2. BCrypt からの署名は 64 バイト形式ですが、android では次のような署名になるシーケンスと長さの識別子が必要です。

3. 署名と検証に使用されたメッセージは、ハッシュされた「Hello World」です。

Android プロセス:

1. 上記の鍵バイト配列から X509 鍵仕様と公開鍵を作成します。

2. AndroidOpenSSL プロバイダーを使用して署名を作成します。

3. 上記のハッシュ配列をロードします。

4. 上記の署名を確認します。

上記の署名とキーは AT チップでチェックアウトされますが (JavaScript-OpenSSL を実行する ECDSA サンプルでも検証されています)、AndroidOpenSSL では検証されません。簡単なものが不足していますか、それともどこに問題があるのでしょうか?

公開鍵構造は ASN.1 デコーダーでチェックアウトされ、コード内で正常に読み込まれ (公開鍵から抽出およびチェックされます)、署名は Java で想定される形式であり、ハッシュ値は両側で同じです。

メッセージの URL-Safe-Base-64 エンコード SHA256+ECDSA 署名である署名を作成する必要があります。これは、リモート REST サービスを利用するために使用されます。

期待どおりに接続する HAL ブラウザーの実装と、SCALA でのテスト実装が提供されました。

C# を使用して同じ署名を生成しようとしています。

これまでのところ、これは私の署名方法がどのように見えるかです

コードをビルドしていますが、無効な署名を作成しています。呼び出し方法はこちら