← 一覧へ戻る

Claude が書いた記事

VPN Gateway の速度は『暗号スイート』で決まる ── pps と AEAD の底

Azure VPN Gateway の SKU 表で、同じ SKU でも暗号アルゴリズムによってトンネルあたりの pps が桁違いになる。VPN の速度は回線の太さでなくゲートウェイ CPU の per-packet 暗号コストで決まり、GCM が速いのは CTR の並列性が AES-NI を満載にできるから。TLS で主流が CBC から GCM に移ったのと同じ理由。

俺の最初の疑問

Azure VPN Gateway の SKU を選ぶページ (about-gateway-skus) に「パフォーマンス別のゲートウェイ SKU」という表がある。そこを見ていて引っかかった。

同じ SKU でも、選ぶ暗号アルゴリズムによってトンネルあたりの数字が変わる。たとえば Generation2 の VpnGw3 で、

アルゴリズムトンネルあたり pps
GCMAES256約 140,000
AES256 + SHA256約 66,000
DES3 + SHA256約 13,000

なんで暗号アルゴリズムで pps (1 秒あたりパケット数) がこんなに変わるんや？ 鍵長で重さが変わるんか？ という素朴な疑問から掘り始めた。

まず一言でいうと

VPN Gateway のスループットは、回線の太さやなくて「ゲートウェイの CPU が 1 パケットあたり暗号処理に何サイクル使うか」で決まる。

だから素直に見るべき指標は Gbps やなくて pps。Gbps はその結果でしかない。

スループット(Gbps) = pps × 1パケットの大きさ
            ↑これは結果      ↑CPUが律速する本体

パケットが来るたびに、ゲートウェイの CPU が「復号する / 暗号する + 改ざんチェックする」をやる。この per-packet の仕事の重さがアルゴリズムで変わる。だから pps が変わる。鍵長の長さの話ではない。

何と比べるとわかるか ── TLS の CBC → GCM 移行と同じ

これは新しい話やなくて、TLS で一度通った道とまったく同じだ。

TLS も昔は AES-CBC + HMAC-SHA の暗号スイートが主流だったが、今は AES-GCM や ChaCha20-Poly1305 に世代交代した。理由は速度と素直さ。VPN Gateway の GCMAES256 はその IPsec 版で、AES256+SHA256 は旧型の CBC+HMAC にあたる。

VPN も TLS も、突き詰めれば「暗号を終端する箱の CPU コスト」の話。App Gateway / Front Door の TLS 終端スループットが暗号スイートで変わるのと、根っこは同じ現象だ。

何が問題なのか ── per-packet コストが変わる 3 つの理由

「1 パス vs 2 パス」だけだと思いがちだが、実際は 3 つの要因が重なっている。効く順に。

① データを「2 周」なめるか「1 周」で済むか。 AES256+SHA256 は AES で暗号化して 1 周なめたあと、HMAC-SHA256 で改ざんチェック用にもう 1 周なめる。GCMAES256 は暗号化しながら同時に認証タグを積むので 1 周で済む。

② 暗号化が「直列」か「並列」か (これが本体)。 同じ AES でもモードが違う。AES-CBC は各ブロックの暗号化が 1 つ前の暗号文に依存する (C_i = E(P_i XOR C_{i-1})) ので、前のブロックが終わるまで次に手をつけられない。CPU に AES-NI という爆速の暗号ユニットが載っていても、前の結果待ちで遊ぶ。一方 GCM の暗号化は CTR モードで、各ブロックが独立カウンタ (E(Ctr_i) XOR P_i)。前を待たず全部まとめてパイプラインに流せるので、AES-NI を詰まらせず満載にできる。

③ 改ざんチェックの道具が違う。 HMAC-SHA256 は重い暗号学的ハッシュ。GCM の認証 (GHASH) は GF(2^128) の掛け算で、PCLMULQDQ という CPU 命令 1 発で加速される。GCM のほうが安い。

図で見る

速い順 ≒ 強い順 ──「遅い＝強い」の逆説

まず素朴な直感を 1 枚で潰しておく。「重い暗号＝強い暗号」と思いがちだが、データは逆を指す。速い順と強い順がほぼ一致していて、3DES だけが「遅くて弱い」隅に落ちる。

速さは『強度』ではなく『現代 CPU に命令 (AES-NI) が生えているか・1 パスか』で決まる。だから一番いいやつ (GCM) が一番速い。3DES は速度も強度も無く、ただの負債。

3DES が遅くて弱いのは「設計が 1998 年で現代 CPU と相性最悪」だから。しかも 64bit ブロックが古く、Sweet32 という攻撃で破られ、NIST も廃止を勧告している (実効強度は ~112bit)。

じゃあ 3DES はなぜまだ選択肢にある？ ── 互換性、しかし閉じていく窓

速度も強度も無い 3DES が表に残っている理由は、ただ一つ「歴史的にどの機器も必ず持っていた最後の共通言語だった」から。VPN は片端 (Azure 側) が速く強くても、対向のオンプレ機器が同じスイートを喋れないと 1 本も繋がらない。だから「最弱でも全員が持っている」3DES が互換性のセーフティネットだった。

ところが、その互換性の優位すら今ひっくり返りつつある。

3 つの差は『強さ』ではなく『いつから広く繋がるか (と速さ)』。AES-CBC は強くて一番広く通る外交的な本命。GCM は登場が遅いぶん古い機は非対応もあるが、両端が現代機なら最速・最強。3DES は昔は新しい機ほど確実に持っていたのに、今は新しい機ほど持っていない。

なぜ GCM が CBC より速いのか ── 直列 vs 並列

理由②を 1 枚に落とす。同じ AES でも、CBC は数珠つなぎで AES-NI が遊び、CTR は全部同時に流して AES-NI を満載にする。この差が速度差の本体だ。

CBC は『前の暗号文』に依存するので数珠つなぎ＝1 レーン直列。CTR は番号札 (独立カウンタ) を配って全部同時＝並列。現代 CPU は並列に流せる仕事を得意とするので、CTR だと AES-NI を満載にでき、完了がずっと早い。GCM はこの上に認証も 1 パスで同時にやる。

名前の非対称 ──「別々合体」か「一体型 (AEAD)」か

最後に名前の謎。AES256 + SHA256 は 2 語なのに GCMAES256 は 1 語。これは見た目だけでなく中身の違いを表している。GCMAES256 も中身は「暗号化 + 改ざん検知」の 2 役で、仕事の数は同じ。違うのは梱包だ。

どちらも『暗号化担当 + 改ざん検知担当』の 2 役。AES + SHA は別々の独立アルゴリズムを後付けで合体 (だから名前に + が付く)。GCM は検知をモードに内蔵した一体型なので足すものが無く名前が 1 語。検知は GHASH (ガロア体の掛け算) であって SHA ではない。一体型 (AEAD) だから 1 パス＆並列にできて速い。

この「暗号化 + 改ざん検知を一体設計したやつ」を AEAD (Authenticated Encryption with Associated Data) と呼ぶ。TLS の AES-GCM や ChaCha20-Poly1305 がこれで、AES-CBC + HMAC-SHA が「別々を組んだ旧型」。VPN の GCMAES256 は IPsec 版の AEAD だ。

混乱しやすいポイント

  • pps が本体、Gbps は結果。 Gbps はパケットサイズを隠す。小さいパケット (VoIP や ACK のような) が多い実トラフィックは、Gbps の数字に届く前に pps の天井に当たる。CPU に正直な指標は pps のほう。
  • 「遅い＝頑丈」は AES-NI が入った時点で崩れた直感。 速さは強度ではなく「現代 CPU の並列性・ハード命令への噛み合い」で決まる。今は強いものを選ぶのが速度的にも正解。
  • GCM の検知は SHA ではなく GHASH。 だから名前に SHA が出てこない。「GCMAES256 は 1 個の処理」ではなく「暗号化 + 検知を 1 つに梱包したもの」。
  • 3DES を選ぶ＝対向が相当古いサイン。 速度でも強度でもなく、化石と繋ぐときの最終手段。

たとえ話

暗号化のモードは「作業レーン」。 CBC は 1 レーンの数珠つなぎ ── 前の塊が出来上がるまで次に手をつけられない。CTR (GCM) は番号札を配って全部同時に処理する複数レーン。同じ職人 (AES-NI) でも、レーンの組み方で捌ける量がまるで変わる。

AES256+SHA256 は別々の職人 2 人を後付けで組ませた状態。鍵屋さん (暗号化) と封印屋さん (改ざん検知) を、プロトコルが「お前ら組め」と紐で縛る。GCMAES256 は暗号化と封印を一体設計した 1 台のマシン。中には同じ 2 つの仕事があるが、最初から噛み合うように作られているので 1 周で終わる。

出てきた言葉の変換表

出てくる言葉つまり何の話？
pps1 秒あたりに捌けるパケット数。VPN ゲートウェイの CPU 律速を表す本体の指標。Gbps = pps × パケットサイズ
GCMAES256AES-256 を GCM モードで動かす AEAD。暗号化 (CTR) + 検知 (GHASH) を一体・1 パス・並列。速くて強い
AES256 + SHA256AES-256 (CBC) で暗号化 + HMAC-SHA256 で検知。別々を後付け合体・2 パス・直列。強いが GCM より遅い
DES3 + SHA2563DES で暗号化。遅くて弱い (実効~112bit, Sweet32, NIST 廃止)。残る理由は互換性だけ
AEAD暗号化と改ざん検知を一体設計した暗号。AES-GCM や ChaCha20-Poly1305。TLS の現行スイートもこれ
AES-NIAES を高速化する CPU 命令。並列に流せる CTR だと満載にできるが、直列の CBC では遊ぶ
GHASH / PCLMULQDQGCM の認証 (ガロア体の掛け算) と、それを加速する CPU 命令。HMAC-SHA より安い。SHA ではない
CTR / CBCAES の動作モード。CTR は並列 (独立カウンタ)、CBC は直列 (前の暗号文に依存)
Sweet3264bit ブロック暗号 (3DES) への誕生日攻撃。3DES が弱い具体的な理由
深掘りメニュー 次におすすめのトピック

今回で「暗号スイートで速度が変わる理由」は底が見えた。残ったモヤは、同じパフォーマンス表の中の別の謎につながっている。

  • なぜ GCM ですら単一トンネルだと頭打ちになるのか ── 実測表で VpnGw4 と VpnGw5 のトンネルあたり pps が同じ (約 220,000) で止まる。これは単一フローが割り当てられるコア数の限界 (RSS / フロー分散) の話。次はこれ。 north-south の単発接続でスループットが出ない理由の底でもある。
  • 集計スループット表 (5G / 10G) と実測表 (2.3G / トンネル) の数字が合わない件 ── 集計は複数トンネルを複数インスタンスに分散して初めて出る数字。「1 本では出ない、束ねて出す」構造。前項とセットで腹に落ちる。
  • ChaCha20-Poly1305 という別の AEAD ── AES-NI が無い / 弱い環境 (古いモバイル等) で AES-GCM より速くなる AEAD。なぜ「ハード命令の有無」で最速の暗号が入れ替わるのかを見ると、今回の「速さ＝CPU への噛み合い」がさらに一段深まる。