まず何を“Diffie-Hellman暗号化”と言っているのか
Diffie-Hellman（DH）は、通信相手と秘密を共有するための「鍵交換」の考え方です。しばしば“暗号化”と一緒に語られますが、実際には、後続の暗号化（平文を暗号文にする処理）に使う共通の鍵を作る役割が中心です。
重要なのは、DHが“誰とでも安全に使える魔法”ではない点です。DHがうまく働くには、合意した鍵が本当に意図した相手のものだと確認できる設計（認証や整合性の仕組み）が必要になります。ここが不足すると、鍵交換の段階で中身をすり替えられる可能性が残ります。
簡単なモデル：相手と同じ鍵を作り、後で暗号化へ進む
直感的には、DHは次の流れで理解できます。
- 各参加者が自分だけが知っている秘密情報（秘密値）を用意する
- その秘密値から計算した公開情報を交換する
- 公開情報と自分の秘密情報を使って、両者が同じ共有鍵を導出する
このとき、交換されるのは“公開情報”です。共有鍵の導出には各参加者の秘密値が必要なので、第三者が公開情報を見ただけでは共有鍵を再現できない、というのが基本方針になります。
ただし、このモデルは「第三者が通信路に介入しても、最終的に合意した相手が本物である」ことを前提に成立します。DH単体では、相手が本当に正しいかどうかを保証しないことがあります。そのため、実運用ではTLSなどのプロトコルに組み込み、認証と整合性保護も含めて総合的に安全性を確保します。
仕組みの中心：鍵交換と鍵導出、そして“認証の有無”
DH鍵交換で得た共有鍵は、そのまま万能に使えるわけではなく、用途に合わせて鍵導出（鍵の作り分け）を行う設計が一般的です。さらに、通信路全体では暗号化だけでなく、改ざん検知（整合性）も必要になります。
ここでの境界が重要です。
- DHは「共有鍵を作る」に強い要素
- 改ざん検知や相手の真正性（“それは本当に相手か”）は、DHだけでは完結しない場合がある
- そのため実際の安全性は、DHを含む上位の設計（認証方式、整合性、プロトコル全体）で決まる
言い換えると、DHを使っているから安心、ではなく「DHがどのように組み込まれているか」を見て判断します。
似ている概念との違い：前方秘匿性、鍵交換、認証
関連概念として、前方秘匿性（フォワードシークレシー）があります。これは、仮に過去に使われた鍵や秘密情報が後から漏れても、過去の通信が即座に復元されにくい性質を指す考え方です。
DH系の鍵交換は、前方秘匿性に関係する設計で使われることがありますが、「あなたの環境が前方秘匿性を実現しているか」は、採用している方式（どの鍵交換パターンか）や実装条件によって変わります。不確実性がある点は、必ず確認が必要です。
また、「鍵交換」と「認証」は別物です。 鍵交換は“同じ鍵を共有する”ことに関係し、認証は“その相手が本物か”に関係します。