ディフィー・ヘルマン鍵交換で「できること」と「できないこと」
Diffie-Hellman鍵交換（DH）は、通信相手と秘密情報を直接共有せずに、同じ「共通鍵」を二者が算出できるようにする考え方です。オンラインリソースへ接続する文脈では、この共通鍵を用いて以降の通信を暗号化したり、メッセージの完全性を確認したりする土台になります。
一方で、DHが単体で解決するのは主に「第三者が通信から共通鍵を推測することの難しさ」です。重要な点として、DH鍵交換そのものには「その相手が本当に意図した相手か」を確かめる仕組みが含まれていない場合があります。そのため、相手の正当性を別の形で担保しないと、なりすましのような別種の攻撃に対して弱くなり得ます。
仕組みを簡単に：公開情報と秘密情報から共通鍵を作る
DHの基本は、次のような流れをイメージすると理解しやすいです。
- 両者が「数学的に関連する公開パラメータ」を共有します（同じルール・同じ土台）。
- 各自がそれぞれ秘密の値を持ち、そこから「公開されても良い値」を計算して相手に渡します。
- 相手から受け取った公開値と、自分の秘密値を使って計算し、「同じ共通鍵」を得ます。
このとき、第三者が共通鍵を求めようとしても、公開情報だけでは計算が簡単に済まない設計（離散対数などに関する難しさ）に依存します。そのため「盗聴しても平文や鍵が直接取れない」方向に寄与します。
安全な接続の条件：認証と暗号の組み合わせが鍵
「安全にオンラインリソースへ接続する」目的を満たすには、少なくとも次の観点が必要になります。
- 盗聴対策：共通鍵が推測されにくいこと（DHの寄与）。
- 相手のなりすまし対策：相手が本物であることを確認できること（認証が必要）。
- 改ざん対策：通信が途中で変えられていないことを検出できること（通常は完全性保護を併用）。
ここで注意点があります。DHは「共通鍵を作る」役割が中心で、相手が正しいかどうかまで保証するのは別コンポーネントです。実運用では、たとえばTLSのように「鍵交換に加えて証明書などによる認証」や「完全性保護」が組み合わされる形で使われることが多いです。結果として、DH鍵交換“だけ”を理解しても、安全性を過大評価しないようにする必要があります。
また、実装や設定によっては、同じDHの考え方でも安全性の強さが変わることがあります。例えば、鍵の長さ、使われるパラメータ、採用する鍵導出や完全性保護の方式などが影響します。したがって、普段の利用では「相手・用途に合った標準プロトコルの既定設定」に沿っているかを確認するのが現実的です。
例外と境界：相手検証が欠けると起きる問題
DHの理解でつまずきやすい境界は「認証がない状況」です。