Diffie-HellmanプロトコルCA、混乱を招く
Diffie-Hellmanプロトコルで、参加者が独自の秘密鍵と生成された公開鍵を持っている場合。認証に信頼できるCAがあるかどうか、または参加者が認証されていない元のプロトコルだけがあるかどうかをどのように判断できますか？
それを指定する必要があるか、メッセージにデジタル署名を付ける必要があるか、または公開鍵が関係する場合はいつでも認証を想定できるか？
Diffie-Hellman（DH）は鍵合意アルゴリズムであり、-共有対称鍵素材の確立に使用されます。
これは「Diffie-Hellmanプロトコル」と呼ばれることもありますが、少し誤解を招く可能性があります。 DHでは、公開鍵などの特定のデータ要素を使用するために、特定の手順を実行する必要があります。ただし、DHプロトコルは正確にwhenを指定していません。これらの手順を実行する必要はなく、これらの手順のビットごとの表現も必要です。さらに悪いことに、DHを実行するさまざまな方法もあります。アイデアだけを得るには、 NIST SP 56 revision スキームを見てください。
INTERLUDE：このドキュメントを読むと、DH自体を使用して認証することが実際に可能であることがわかります。そのためには、認証を行う側で信頼できる公開鍵を使用できる必要があります。つまり、認証されるエンティティにstaticキーペアを使用します。通常、これはDH（またはECDH）証明書を使用して行うことができます。しかし、それらは実際の生活ではほとんど見つかりません。ほとんどの証明書は、DHキーの確立ではなく、デジタル署名に依存しています。
エンティティが信頼されている場合とその方法上位プロトコルに依存。 a transport protocol TLSなど。最新のTLSバージョン1.3では、いわゆるephemeral-ephemeral Diffie-Hellman鍵合意が必須として使用されます。その場合、鍵合意は認証部分から分離されます。DHパラメーターは単に最終認証に含まれるだけですが、合意自体はその中で役割を果たしません。
これは、信頼できるCA証明書の存在は、発生するX.509v3ベースの認証フェーズを調べることによってのみ検出できることも意味しますafter DHキーの確立。つまり、DHが発生した場合はもちろんです。あなたはそれを例えばのために期待するでしょう。サーバー認証ですが、他の認証方法も導入できます。
長い説明の後の短い答え：ええ、それを実装しようとする残りの上位レベルのプロトコルと一緒にそれを指定する必要があります。
参加者が独自の秘密鍵と生成された公開鍵を持っている場合
Diffie-Hellmanには公開鍵と秘密鍵がありません。アリス、ボブ、イブの3人以上の部屋にいるとします。アリスとボブはプライベートに話したい（そして別の部屋に入るのは簡単すぎる）ので、アリスはディフィーヘルマンを使うことを提案します：
Alice： DH鍵の交換をしましょう。乱数を選び、5をその数で累乗します。結果を23で割り、残りを教えてください。
アリスが16を選ぶ5**16=152587890625、23で除算したときの余りは3です。
ボブピック25、5**25=298023223876953125、23で除算したときの余りは10です
ボブ： 10。
Alice：私は3を取得しました。今度は私の数値をその数値で累乗し、再度23で除算して、残りを計算します。
アリスはボブの10を16乗します10**16=10000000000000000、23で除算したときの余り、10000000000000000%23=4
ボブはアリスの3を25で累乗します、3**25=847288609443、23で除算したときの余り、847288609443%23=4
彼らは同じ結果を得た。彼らはイブが知らない共通の番号を持っています。 Eveは、アリスがボブに3を送信し、ボブがアリスに10を送信したことだけを聞きました。彼女は数4を計算できません。
Alice： AESにこのキーを使用して、暗号化して話しましょう！
もちろん、現実の世界では、その数ははるかに大きくなっています。 AESのパスワードが「4」であると推測することはそれほど難しくありません。
それを指定する必要があるか、メッセージにデジタル署名を付ける必要があるか、または公開鍵が関係する場合はいつでも認証を想定できるか？
上記の例では、アリスとボブはお互いを見ることができます。アリスが話した場合、ボブはそれがアリスであることがわかります。インターネットでは、そうではありません。これは、手紙によるコミュニケーションに似ています。メールを配信する人はだれでも偽の手紙を差し込むことができます。
したがって、この交換にデジタル署名を行う必要があります。これは、途中の（女性）が会話に何も注入しないようにするためです。 Diffie-Hellmanはこれを行うことができないため、追加のアルゴリズム、つまり公開鍵と秘密鍵を使用するアルゴリズムが必要です。これを行う最も一般的なシステムは、RSAアルゴリズムと楕円曲線暗号です。
デジタル署名のしくみについては、他の場所で詳しく説明されています。上記の会話（Aliceがパラメーター5と23、Bobが10と言い、Aliceが3と言うところ）にデジタル署名を適用するだけで、認証済みの鍵交換プロトコルができます。
しかし、公開鍵を交換するために、同じ問題があります。どのようにして、真ん中の誰もが自分の公開鍵に本当の公開鍵を切り替えなかったことをどうやって知るのですか？これが認証局（CA）の用途です。これらは信頼できるサードパーティであり、公開鍵にデジタル署名を付けます。これを解決する別の方法は、TOFU：Trust On First Useです。これには、最初の通信がすでに傍受されている場合、通信が危険にさらされるという欠点があります。ただし、CAシステムが不要であり、したがって侵害される可能性のあるCAがないという利点があります。