まず結論：Diffie-Hellmanは「共有秘密づくり」。安全性は認証と構成で決まります

Diffie-Hellman（DH）暗号化という言い方は、文脈によって少し混ざりますが、中心となるのは「鍵交換」です。DHは、直接共有していない情報から、お互いが同じ共有秘密を計算できるようにする仕組みです。その共有秘密を使って、後段の通信暗号（たとえば対称鍵暗号）を成立させます。

ただしDHそのものが“通信を勝手に安全にしてくれる”魔法ではありません。攻撃者が途中に入る状況では、相手の正当性を確かめる認証（認証付き鍵交換、証明書、署名など）が不十分だと、共有秘密が別物になってしまう可能性があります。さらに、鍵交換が強くても、後段の暗号方式や整合性保護が弱いと意味が薄れます。

仕組み（わかりやすいモデル）：公開パラメータと公開情報から共有秘密を作る

DHの基本の考え方は、次のように捉えると理解しやすいです。

  • 事前に「数学的に公開してよいパラメータ」（例：大きな素数や生成元に相当する値）が用意されます
  • 通信開始時、各側はランダムな秘密値を持ちます（相手に秘密のまま保持）
  • それぞれが自分の秘密値から計算した“公開できる値”を相手に渡します
  • 相手から受け取った公開値と、自分の秘密値を組み合わせて、同じ共有秘密を計算できます

この流れで重要なのは、「共有秘密を推測するには、相手の秘密値（ないしそれに相当する推測困難性）が必要になる」ように設計されていることです。つまり、DHが得意なのは“鍵交換”であり、通信の中身を直接置き換えるのは、通常この後に使う暗号（暗号化と復号、改ざん検知）が担います。

また、実際のプロトコルでは「前方秘匿性（過去通信の鍵が後から漏れても、過去が全部復元できない方向にする）」のような設計が組み合わされることがあります。ここは方式・実装・設定に依存するため、必ずしも“どのDHでも同じ効果がある”と断言できません。

部分的な強さと制限：DHが強くても安全とは限らない

DHには、理解しておくべき制限や“安全性が変わる要因”があります。

  1. 相手認証がないと、なりすまし耐性が弱くなる DHは鍵交換ですが、相手が本物かどうかを確認しない設計だと、中間者が介入して別の共有秘密を作らせる余地が残ります。実運用では、証明書や署名で相手を認証し、鍵の導出が正しい相手に結び付くようにします。

  2. 鍵交換だけでなく、通信全体の暗号スイートが重要 後段で使われる暗号方式、特に“改ざん検知（完全性）”をどれだけ確実に行えるかが結果を左右します。暗号化だけあって改ざん検知が弱いと、攻撃者は内容の破壊や特定の攻撃を試みやすくなります。

  3. パラメータや方式の選択が安全性を左右する 一般に、鍵交換で用いるパラメータが小さすぎる、古い方式が選ばれる、実装が特定の条件で脆弱になる、といった問題が起こり得ます。