定義:Diffie-Hellman暗号化とは何をする仕組みか

Diffie-Hellman(DH)は、共有の秘密(共有鍵)を、片方が相手にその秘密自体を送らなくても作れるようにする鍵交換の考え方です。ここで作られる共有鍵は、その後の暗号化(たとえば対称鍵暗号)やメッセージ認証に使われます。つまりDHは「暗号化そのもの」よりも、暗号化に必要な鍵を合意する役割が中心です。

わかりやすい仕組み:共有鍵を“別々に”計算する

典型的なDHの流れは、概略として次の理解で十分です。

  • 公開にしてよい情報(公開パラメータ)と、各当事者が持つ秘密の値(秘密鍵のようなもの)を用意します。
  • 各当事者は自分の秘密値を使って「公開情報」を計算し、相手へ送ります。
  • 相手から受け取った公開情報と、自分の秘密値を組み合わせて、同じ共有鍵を計算します。

このとき、第三者が通信内容(公開情報やプロトコル上のデータ)だけを見ても、共有鍵に必要な“秘密値”を直接復元できないことを安全性の前提にします。ここで重要なのは「公開情報から秘密鍵が求まらない(解きにくい)」という数学的性質です。ただし、その性質を現実の安全性に変えるには、パラメータ選定やプロトコル全体の作り込みが不可欠です。

世界水準になり得る理由:鍵交換としての強み

DH系が広く使われるのは、次の理由によります。

  • 事前に共有鍵を配る必要がなく、通信ごとに鍵を作り直しやすい
  • 公開情報は送るが、共有鍵自体は秘密値からしか計算できない設計にできる

さらに、プロトコルによっては「前方秘匿性」に関わる構成(後述)を組み込み、将来の情報漏えいがあっても過去通信の共有鍵が直接は導けない形を狙えます。もっとも、前方秘匿性が本当に得られているかは“方式と設定”に依存します。

制限と落とし穴:認証がないと安全性が崩れる

DHが鍵交換として優れていても、「認証(本当に相手が誰かを確認する仕組み)」がないと、別の攻撃が成立しやすくなります。代表例は中間者攻撃です。

  • 攻撃者が通信経路に割り込み、当事者AにはAのふりをしつつ、当事者BにはBのふりをして鍵交換を“別々に”成立させる
  • 結果として、Aと攻撃者、攻撃者とBの間では別々の共有鍵が作られ、攻撃者が内容を読める可能性が生じる

このため、DHを含む通信では、証明書や署名などで相手を認証し、さらにハンドシェイク全体を整合させる設計が重要になります。加えて、実装がパラメータの扱いを誤る、古い方式や弱いパラメータを許してしまう、といった不具合があると、理論どおりになりません。

関連概念:前方秘匿性・(EC)DH・ハンドシェイクの整合

ここでは混同されやすい要点だけ整理します。 - 前方秘匿性:ある時点で長期秘密が漏れたとしても、過去の通信鍵(共有鍵)が推定されにくい性質を指します。 DHを使う場合でも、どのように鍵を毎回作るかで結果が変わります。