まず結論：DHは「鍵交換」であり、安全性は認証で決まる

Diffie-Hellman暗号化（DH）は、通信相手と同じ共有鍵を作るための仕組み（鍵交換）です。共有鍵が作れた後の「実際の暗号化」や「改ざん検知」は、通常その共有鍵を使う別の機構（例：暗号化アルゴリズムや完全性検証）に依存します。重要なのは、DHそのものは“相手が本物か”を自動で保証しない点です。認証がない構成では、中間者攻撃により鍵交換内容をすり替えられる可能性があります。

仕組み：公開情報と秘密情報から同じ共有鍵を導く

DHでは、各当事者が次のような役割を担います。

  • 公開できる値（例：素数に関する情報や生成に使う値）
  • 秘密として保持する値（各自でランダムに選ぶ数）

概念的には、相手の公開値を受け取って計算を行うことで、自分だけの秘密値と相手の公開値の組み合わせから、最終的に同じ共有鍵に到達します。ポイントは「自分が持つ秘密値」と「相手から受け取れる情報」から“同じ共有値”が計算できる一方で、盗聴者がそれを直接復元するのが難しい設計になっていることです。

ただし、ここで言う“難しさ”は、計算量の前提やパラメータ選びに左右されます。たとえば、弱すぎる公開パラメータや不適切な実装は、理論上の安全性を損ねることがあります。そのためDHを「暗号として安全だ」と言い切るには、鍵交換がどの形で使われ、どのような前提を満たしているかまで含めて判断する必要があります。

部品としての位置づけ：DH単体では“安全なネットワーク”にならない

「安全なネットワーク」を達成するには、少なくとも次の要素が組み合わさる必要があります。

  • 機密性：通信内容が第三者に読まれにくいこと
  • 完全性：改ざんされにくい／検知できること
  • 認証：相手が本物であること（少なくとも通信相手を取り違えないこと）

DHは主に「認証なしに共有鍵を合意する」方向の技術です。合意できた共有鍵を使って、暗号化（機密性）や完全性（改ざん検知）を行うことが多いものの、“認証”をどう扱うかは別途設計されます。結果として、DHを用いても、認証や完全性が適切でなければ安全性は十分になりません。

代表的な制限と注意点：中間者攻撃とパラメータ/実装の落とし穴

認証がない場合の中間者リスク

DHで共有鍵を作る過程は公開される要素を含みます。そのため、当事者のどちらも「相手が誰か」を検証しない構成だと、第三者が鍵交換の途中に入り込んで別の相手として振る舞い、独自の共有鍵を成立させてしまう可能性があります。これは“DHが破られた”というより、“鍵交換後に誰と通信しているかが保証されない”問題です。

パラメータと実装の前提

DHは「公開パラメータ」と「秘密値の選び方」によって実際の強度が変わり得ます。