まず結論：Diffie-Hellmanは「共有鍵を作る」技術で、セキュリティは認証とセットで決まる

Diffie-Hellman（DH）暗号化（厳密には鍵交換）は、両者が互いに秘密を保ちながら共通の「共有鍵」を導くための仕組みです。共有鍵が作れれば、その後の暗号通信（例：通信データの暗号化）に使えます。 ただし、DHそのものは「その相手が本当に正しい相手か」を保証しません。相手の正当性を確認する仕組み（認証）が欠ける、または不適切だと、中間者（攻撃者）が通信に入り込む余地が生まれます。したがって「高いレベルのオンラインセキュリティ」を目指すなら、DHを使っているかだけでなく、認証と組み合わせて成立しているかまで確認する必要があります。

仕組み（簡単なモデル）：公開情報から共有鍵を作る

DHの基本イメージは次の通りです。

  • それぞれが自分だけが知る秘密値を持つ
  • その秘密値から計算した値を相手に送る（この送信値は“公開”として扱う）
  • 相手から受け取った値と、自分の秘密値を使って共有鍵を計算する
  • 同じ共有鍵を、双方が同じように得られる

ここで重要なのは、送った公開側の情報だけでは共有鍵を計算しにくい設計になっている点です。結果として、通信を盗み見している第三者が、送信された値だけから共有鍵を直接導けないようにします。

主要な構成要素：鍵交換と「認証」「完全性」「暗号方式」は別物

オンラインセキュリティは複数の要素の組み合わせで成り立ちます。

  • 鍵交換（Diffie-Hellman）：共有鍵を作る
  • 認証：相手が本当に意図した相手かを確認する（なければ“なりすまし”が成立しやすい）
  • 完全性（改ざん検出）：途中で内容が変えられていないかを検出する
  • 暗号方式：共有鍵で実際にデータを暗号化する

つまり「DHを使えば全部安全」とは言い切れません。DHが強くても、認証が成立していなかったり、完全性が弱かったりすると、攻撃の成立条件が変わります。

制限と例外：中間者攻撃の成立条件、古い実装のリスク

DHが弱くなる典型は、「相手の正しさ」を検証できないケースです。例えば次のような状況では、攻撃者が両者の間に割り込み、双方それぞれと別々の鍵交換を成立させようとする余地が生まれます。これを防ぐには、通信の相手が正しいことを示す仕組みが必要です。

また、DHを含む鍵交換の“強度”は、使われるパラメータ（素数や生成元など）や実装の品質にも左右されます。古い方式や古い設定が残っていると、想定していた前提（安全性の根拠）が弱まることがあります。したがって、実現したいのは「DHという名前」ではなく、「現実の設定・方式が安全な前提で動いていること」です。

実践的な確認方法：観測できる手がかりを“鍵交換＋認証”で見る

ここでは、個別製品の推奨ではなく、一般に確認しやすい観点を挙げます。