まず定義：Diffie-Hellman暗号化は何をするのか

Diffie-Hellman（ディフィー・ヘルマン）暗号化は、双方が同じ「共有鍵」を作れるようにする公開鍵方式の一種です。重要なのは、共有鍵そのものを最初から相手に送らない点です。双方は公開情報をやり取りし、その結果として同じ共有鍵を導き出します。この共有鍵を使って、その後の通信を暗号化すれば、第三者が通信内容を読み取ることを難しくできます。

ただし、Diffie-Hellmanが自動的に「完全に安全」になるわけではありません。通信の相手が本当に正しい相手だと確認する仕組み（認証）が別途必要になることがあります。ここが、理解の出発点です。

簡単な仕組み：共有鍵を“公開情報から”作る

Diffie-Hellmanの基本イメージは次の通りです。

  1. 各参加者は自分だけが知る秘密の値（秘密鍵）を持つ
  2. 秘密鍵から計算した公開値（公開鍵）を相手に送る
  3. 相手から受け取った公開値と、自分の秘密鍵を用いて共有鍵を計算する

相手も同じ手順で同じ共有鍵に到達できるため、両者の間で暗号化・復号に使える鍵がそろいます。第三者は公開値を見られても共有鍵を直接導けない、という考え方に基づいています。

安全性の制限：認証がないとMITMに弱くなる

Diffie-Hellmanで共有鍵が作れても、「相手が誰か」を確かめなければリスクが残ります。代表例が中間者攻撃（MITM）です。

たとえば攻撃者が、あなたと本来の相手の間に入り込み、それぞれと別々にDiffie-Hellmanの鍵共有を成立させられる状況だとします。この場合、あなたから見ると共有鍵は“相手と合意したもの”に見えますが、実際には攻撃者が関与した別の鍵になっている可能性があります。結果として、通信は攻撃者に復号・再暗号化され得ます。

そのため設計上は、鍵共有に加えて、次のような追加要素が必要になります。

  • 相手の正当性を示す仕組み（認証）
  • どのアルゴリズムや鍵交換方式を使っているかの整合
  • その“握手”が改ざんされていないことの確認

実務では、これらをTLSなどのプロトコルの中で一体として扱うことが多いです（ただし、どの設定が有効かは環境依存で、単に方式名だけでは判断できません）。

関連概念：TLS、証明書、パラメータの役割

Diffie-Hellmanは単体の鍵共有機構であり、通信全体の安全性は周辺要素との組み合わせで決まります。特に、次が関連します。

  • TLS（または同等の仕組み） 通信プロトコル側で鍵交換や暗号化、整合性（改ざん検出）などをまとめて扱うのが一般的です。

  • 証明書（相手の認証に関わる） MITMを避けるには「相手が本物である」ことの確認が必要になる場合があり、その役割を証明書が担います。ただし、証明書の検証方法や運用は実装・設定に依存するため、どれが有効かは確認が要ります。