WireGuard の暗号設計：Noise プロトコルとハンドシェイク

WireGuard が「選ばない」ことで得たもの

IPsec や OpenVPN は、鍵交換・暗号・ハッシュ・認証をそれぞれネゴシエートできる柔軟さを持ちます。しかしその柔軟さは、暗号スイートのダウングレード、相互運用のための弱い設定の残存、巨大な設定項目という代償を伴いました。WireGuard はこの方針を反転させ、暗号アルゴリズムを1組に固定 します。

• 鍵交換：Curve25519（X25519 による ECDH）
• AEAD 暗号：ChaCha20-Poly1305
• ハッシュ：BLAKE2s
• ハンドシェイク骨格：Noise Protocol Framework の Noise_IK パターン

選べないため、ネゴシエーション自体が存在しません。ClientHello に相当する暗号スイート一覧の交換がなく、ダウングレード攻撃の入り込む余地が原理的になくなります。アルゴリズムに将来欠陥が見つかった場合は、プロトコルのバージョンを上げて入れ替える方針（暗号的アジリティをプロトコル外に追い出す設計）です。VPN 全体像は /network/vpn/ を、対比対象の鍵スケジュールは /network/tls13-handshake-internals/ を参照してください。

Noise_IK ハンドシェイク

Noise の命名 IK は、開始側（Initiator）の静的鍵が応答側に Immediately（メッセージに同梱）送られ、応答側（Responder）の静的鍵は開始側が事前に Known（既知）であることを表します。WireGuard では、接続を始める前から両者が相手の公開鍵を設定で知っているため、この前提が成立します。

ハンドシェイクは2メッセージ（1往復）で鍵が確立し、続く Data で全二重通信に入ります。-> が開始側送信、<- が応答側送信です。

->  Handshake Initiation
      unencrypted_ephemeral   (開始側の一時公開鍵 g^e_i)
      encrypted_static        (開始側の静的公開鍵を暗号化して同梱)
      encrypted_timestamp     (TAI64N タイムスタンプ、リプレイ防止)
<-  Handshake Response
      unencrypted_ephemeral   (応答側の一時公開鍵 g^e_r)
      encrypted_nothing       (空のペイロード＝相互認証の確認)
->  [Transport Data]          確立した鍵で ChaCha20-Poly1305 暗号化

このハンドシェイク中、両者は段階ごとに 複数の Diffie-Hellman を合成 します。一時鍵 e と静的鍵 s の組み合わせで、ee・es・se・ss のうち必要なものを連鎖的にハッシュへ混ぜ込み、チェイニングキーを更新していきます。一時鍵が入る DH があることで 前方秘匿性 が、静的鍵が入る DH があることで 相手の同一性認証 が同時に得られます。

cryptokey routing：公開鍵がそのまま宛先

WireGuard の中核概念が cryptokey routing です。各ピアには公開鍵と AllowedIPs（そのピア宛・そのピア由来として許す IP レンジ）が結び付きます。これが送受信の両方向で機能します。

送信時: 宛先 IP -> AllowedIPs で一致するピアを検索 -> そのピアの鍵で暗号化
受信時: 復号して送信元ピアを特定 -> 平文の送信元 IP が
        そのピアの AllowedIPs に含まれるか検証 -> 含まなければ破棄

つまり「どの鍵で暗号化するか」と「どこへ送るか」が同じ表で決まり、暗号とルーティングが一体化しています。受信側では、復号して鍵で身元が確定したうえで、内側パケットの送信元 IP が許可レンジ内かを照合します。これにより、正規ピアであっても許可外の IP を詐称した内側パケットは拒否され、IP スプーフィングに対する強い境界になります。VPN がアドレス変換と絡む点は /network/nat/ も参照してください。

ステートレス性とローミング耐性

従来 VPN の多くは、確立したセッションを「対向の IP アドレスとポート」に強く結び付けます。そのため対向の NAT マッピングが変わったり、Wi-Fi からモバイル回線へ切り替わったりすると、セッションが切れて再ハンドシェイクが必要でした。

WireGuard はトランスポートパケットを受信して復号・認証に成功すると、その送信元 IP/ポートを そのピアの最新エンドポイントとして学習し直します。鍵が一致すれば中身が本物だと確定するので、送信元アドレスが前回と違っても問題ありません。結果として、対向が移動・NAT 変更しても トンネルは張り直さずに継続 します。これがローミング耐性です。

さらに WireGuard は、トラフィックが流れていない間は 一切パケットを送らない 完全な無通信状態を取れます。常時 keepalive を流す必要がなく、サーバーは接続中のクライアント分の常駐セッション状態を最小限しか持ちません。攻撃面の観点でも重要なのが、ハンドシェイク前の段階では応答側が状態をほとんど作らない設計（および後述の Cookie）で、未認証の相手からのリソース枯渇を避けている点です。

DoS 耐性：暗号化 Cookie

公開鍵暗号の DH 計算は CPU を消費するため、攻撃者が偽の Handshake Initiation を大量に送ると応答側を疲弊させられます。WireGuard は負荷が高いとき、応答の代わりに 暗号化された Cookie を返します。Cookie は受信パケットの送信元 IP から導出され、開始側は次回ハンドシェイクにこの Cookie を付けて「自分はその IP から本当に応答を受け取れる」ことを示します。

これにより、送信元 IP を詐称した攻撃者は有効な Cookie を得られず、DH 計算を伴うハンドシェイク処理まで到達できません。TLS や TCP の防御機構と同様、状態を持たされる前に往復可能性を確認する発想です。トランスポート土台の挙動は /network/tcp-udp/ を参照してください。

従来 VPN との対比

実務で確認するコマンド

# 鍵ペアの生成（秘密鍵から公開鍵を導出）
wg genkey | tee private.key | wg pubkey > public.key

# 現在のピア・最新ハンドシェイク時刻・エンドポイントを確認
wg show wg0

# ハンドシェイクの経過時間が更新され続けるか（ローミング後も継続するか）を観察
watch -n1 'wg show wg0 latest-handshakes'

latest-handshakes の値はおよそ2分ごとに更新され、endpoint 行は対向が移動するたびに学習し直されます。暗号スイートを固定して Noise_IK に一本化し、鍵そのものをルーティング判断に使う——この「選ばない設計」が、WireGuard の小ささ・速さ・ローミング耐性をまとめて生み出しています。鍵交換から完全性検証までを1つのトランスクリプトに束ねる発想は /network/tls13-handshake-internals/ と通底しており、対比して読むと設計思想の違いが鮮明になります。