ほとんどの暗号では、適切なノンスが非常に重要であることを理解しています。私は AES-GCM を使用しており、256 ビットの AES キーで 96 ビットの nonce を使用しています。セキュリティで保護されていないチャネルを介して nonce をネゴシエートする方法について、ここで以前にいくつか質問しました。
私は ECDH を使用して共有シークレットを導出し、X9.63 標準メソッドを使用してキーイング マテリアルを導出する予定です。キーをネゴシエートするときに、ソルトの末尾にランダムに生成された 96 ビットを追加するだけでよいことはわかっています。次に、XOR のように (これはピア ツー ピア システムです) 何らかの方法で 2 つを組み合わせて、ランダムで適切なナンスを持つことができます。
もちろん、これは ARP なりすましなどの MITM 攻撃を阻止するものではありません。公開鍵自体は、公開鍵がアプリケーションとともに配布される中央サーバーによって認証されます。したがって、GCM を使用しているため、証明書を改ざんすることはできません。ただし、ナンスはもちろん認定されていないため、キーを同一に保ちながら、IVを予測可能なものまたは静的なもの（またはすべてゼロなど）に置き換えると、ピアをMITMする可能性があります。これにより、選択された（既知の？）平文攻撃。
紛らわしい場合に備えて、私が話していることのシナリオを次に示します。Alice (A) と Bob (B) はどちらも、適切なランダムな 96 ビット nonce マテリアル (Am と Bm) を生成し、x.509 証明書に追加します。説明のために、小さな数字 Am=1234 と Bm=4321 を使用します。MITMed でない場合、それぞれが Am⊕Bm = 5171 を計算します。これが nonce として使用されます。イブは、IVを倒すためにそれらをMITMすることにしました。彼女は、彼らが一定の IV「6666」で終わることを確認します。A が Am "1234" を B に送信すると、Eve ARP は Bm を偽装し、これを "2795" に置き換えます。BがBm「4321」をAに送ると、Eveはこれを「7896」に置き換えます。1234⊕7896 == 4312⊕2795 == 6666.
ここに私の考え/考えがあります：
nonce マテリアルに署名鍵 (ECDSA) で署名する: この時点で、GCM 自体以外のものを認証する機能はありません (つまり、ECDSA キーを使用したり管理したりしていません)。Suite B アルゴリズムに厳密に固執したいと思います。GCM（AEADの「AD」部分-関連データによる認証済み暗号化）でプレーンテキストを認証できることは知っていますが、もちろん、まだIVを確立していません...したがって、これでIV素材を認証することはできません。私？とにかく暗号化する必要がないため、GCMとの対称キーのみを使用してこれを認証できるように思われます（ECDHを介してすでに確立しています）ので、秘密はありません-プレーンテキストとGCM MACだけです-- しかし、BC で IV なしで AEADBlockCipher を初期化する方法がわかりません。「だます」のはばかげているでしょうか？最初にすべてゼロの IV、正しい鍵で暗号を初期化してから、ナンスを「関連付けられたデータ」(暗号化されていない) として処理し、(MAC を追加するために) バッファをファイナライズし、これをピアに送信してから、本物のIVと同じ鍵で暗号化？あるいは、ECDSA を使用してノンスに署名できると確信しています (おそらく、必要に応じて ECDH 公開鍵と共に)。ただし、それには、サーバーによっても認証されている ECDSA 公開鍵を配布する必要があり、複雑さが増します。むしろ避けてください（したがって、私の最初の署名のアイデア）
同じ IV/キー コンボの繰り返し使用を記録して禁止する: IV で重要なことは、指定されたキーで一度しか使用されないことです。したがって、誰かが上記の MITM 攻撃を繰り返し行って IV を人為的なものに置き換えると、このアイデアは単に接続を認識して閉じるだけです。未使用の IV を導出する有効な代替ペアでそれを置き換えた場合、攻撃者は何の利点も得られません (そうですか?)。私の設計の ECDH ペアの秘密鍵は、実際にはディスクにヒットしないため、プログラムの呼び出しの間にすべての新しい対称鍵が作成されるため、このキー + IV ペアのセットを簡単にメモリに保持できるため、このアプローチが本当に気に入っています:- )
ECDHの秘密素材を「マスク」として使用し、秘密のIVを作成: 確立された ECDH シークレット マテリアルを取得します (まだ X9.63 キー ジェネレーター (BC の ECDHKEKGenerator) に渡されていません)。マテリアル自体の最初の 96 ビットや、マテリアルの SHA-1 ダイジェストの最初の 96 ビットなど、何らかの方法でそれ (Km) から 96 ビットを取得します。Alice と Bob は、ランダムな 96 ビット nonce マテリアル (Am と Bm) を生成します。A と B はそれぞれ Am⊕Km と Bm⊕Km を計算し、その値を相手に送信します。A が Bm⊕Km を持ち、B が Am⊕Km を持っている場合、A は Km⊕(Bm⊕Km) を実行して Bm を取得し、B は Km⊕(Am⊕Km) を実行して Am を取得します。次に、A と B の両方が Am⊕Bm を実行し、最終的に IV を取得します。イブはKmを知らないので、正確に操作できないので、改ざんされた場合、AとBのIVが異なりますよね？これにより、最初のメッセージが交換されたときに GCM が改ざんを検出するため、害はありません。このアプローチの何が問題なのですか?
長い質問で申し訳ありませんが、自分のプロトコルを実装しないように言わないでください。CS の学生として実装の詳細を学ぶためにこれを行っているためです。それらを無視する方法ではありません。