まず結論：Diffie-Hellmanは「鍵を共有する」ための仕組み
Diffie-Hellman（DH）暗号化は、双方がやり取りの前に秘密鍵を持ちつつ、公開情報を使って「同じ共通鍵」を作る鍵交換方式です。その共通鍵を使えば、以降の通信内容を暗号化して盗聴リスクを下げられます。
ただし、ここで重要なのは役割の切り分けです。DHは主に「暗号化の土台（共通鍵）」を用意します。一方で、相手が本当に本人（正しいサーバー／相手）かどうかを保証する機能は、DH単体では提供しません。オンライン・アイデンティティ（ログイン情報やアカウントに結びつく情報）を守るには、暗号化に加えて「正しい相手であることの確認」が必要になります。
仕組みの全体像：共通鍵を“公開しないで”作る
DHでは、次の考え方で共通鍵を得ます。
- 各当事者は自分だけが知る秘密（秘密鍵）を用意します。
- その秘密を反映した公開情報（公開値）を相手に送ります。
- 相手から受け取った公開値と自分の秘密から、両者が同じ共通鍵を計算します。
直感的には、「秘密鍵は公開しない」「公開しても共通鍵がそのまま分からない」ように数学的に設計された関係を利用します。そのため、第三者が通信を盗み見ても、共通鍵までは直接復元できない前提が置かれます。
さらに実運用では、DHをそのまま単独で使うというより、別の仕組み（通信規約や認証、改ざん検出など）と組み合わせて使われることが多いです。その結果として「通信の機密性（盗聴への耐性）」や「完全性（改ざん検出）」が成立します。
オンライン・アイデンティティ保護での制限：DH＝本人確認ではない
オンライン・アイデンティティを守る文脈では、次の理解が欠かせません。
- DHで守れるのは主に“内容”：第三者が通信内容を読みにくくする方向に働きます。
- 本人確認は別レイヤーの課題：相手が本物か（どのサーバー／相手に接続しているか）を保証するには、証明書の検証や署名の確認など、DH以外の要素が必要になります。
このギャップがあるため、もし攻撃者が通信の途中に入り込み、当事者同士を別々に繋いでしまうと、DHで作った共通鍵をそれぞれ攻撃者が“都合よく”成立させる状況が起こり得ます（いわゆる中間者攻撃の典型的な考え方）。もちろん実際の被害の可否は、利用するプロトコルや検証手順、設定に大きく依存しますが、DH単体では「相手が正しい」ことの裏取りができない点は変わりません。
記憶しておく違い：暗号化・鍵交換・認証
関連概念を、混同しやすい順に整理します。
- 鍵交換（Diffie-Hellman）：共通鍵を作るための仕組み。主眼は“鍵の共有”。
- 暗号化：共通鍵で通信内容を読めない形にすること。主眼は“機密性”。
- 認証：相手（サーバーや相手端末）が本物かを確認すること。主眼は“正当性”。
DHで共通鍵が成立しても、認証が弱い／無効だと「正しい相手に繋いだ」という前提が崩れます。