15

BouncyCastle を暗号化プロバイダーとして使用するネットワーク アプリケーションを構築しています。キーペアを生成するためにこれがあるとしましょう：

ECParameterSpec ecSpec = ECNamedCurveTable.getParameterSpec("prime192v1");
KeyPairGenerator g = KeyPairGenerator.getInstance("ECDSA", "BC");
g.initialize(ecSpec, new SecureRandom());
KeyPair pair = g.generateKeyPair();

ECDSA KeyPairGeneratorのインスタンスを取得している理由がわかりません。ECとしか言わないのはなぜですか？BouncyCastle に同梱されている ECDH キー タイプがあることは知っていますが、この 2 つは曲線上のポイントについて同じものを表していると思いました。それとも、その背後にある理論に完全に誤りがありますか?

私が尋ねる理由は、現在、私のアプリケーションは ECDH を使用して AES 秘密鍵を確立していますが、ECDSA を使用して各メッセージに署名するために同じ EC キーを使用したいからです。

4

1 に答える 1

32

ECDSA と ECDH は異なる標準 (それぞれ ANSI X9.62 と X9.63) に基づいており、異なるコンテキストで使用されます。X9.63 は、公開鍵の標準表現 (X.509 証明書など) を含め、X9.62 の要素を明示的に再利用します。したがって、ECDSA と ECDH のキー ペアはほとんど交換可能です。ただし、特定の実装がそのような交換を許可するかどうかは未解決の問題です。歴史的に、(EC)DSA と (EC)DH は異なる世界から来ています。

ただし、使用コンテキストはまったく異なることに注意してください。暗号化には、楕円曲線の計算よりも少し多くのことがあります。「鍵のライフサイクル」を考慮する必要があります。平たく言えば、鍵合意鍵と署名鍵を同じ手順で管理したくありません。たとえば、キー合意キーを紛失した場合 (あなたの犬があなたのスマートカードを食べてしまいます -- 笑わないでください、実際に起こります)、そのキーに対して相対的に暗号化されたデータ (たとえば、あなたに送信された暗号化された電子メール、および暗号化された形式で保存されます)。ビジネスの観点からは、鍵の紛失は従業員の紛失にもなり得ます (従業員が解雇され、バスに轢かれた、または退職したなど)。したがって、暗号鍵 (鍵合意鍵を含む) はしばしばエスクローする必要があります (たとえば、秘密鍵のコピーが印刷され、金庫に保管されます)。一方、署名キーを紛失しても、データが失われないことを意味します。以前に発行された署名は引き続き検証できます。このような損失からの回復は、新しいキー ペアを作成するのと同じくらい簡単です。ただし、エスクロー システムが存在すると、署名に添付される可能性のある法的価値が署名から自動的に剥奪される傾向があります。

また、より一般的に言えば、2 つの異なるアルゴリズムで同じ秘密鍵を使用しないことを強くお勧めします。アルゴリズム間の相互作用は完全には調査されていません (単に 1 つのアルゴリズムを研究するだけでも大変な作業です)。たとえば、同じ秘密鍵で計算した ECDSA 署名から抽出した曲線ポイントを誰かが ECDH ベースのプロトコルに送り始めたらどうなるでしょうか?

したがって、ECDH と ECDSA に同じキーを再利用するべきではありません。

于 2011-02-11T15:13:00.527 に答える