どちらの名前も AEAD の構成です。どちらも標準化されており、現在の x86 サーバーならどちらでも目に見える苦労なくギガビット回線を埋め尽くします。選択が恣意的でなくなるのは、そのサーバーを離れるときです。安価なルーター、古いスマートフォン、仮想アプライアンスには AES 高速化がないことが多く、そこでは差が大きくなります。つまり比較はどちらの暗号が速いかではなく、この端点の集合でどちらがよく動くか、そしてプロトコルがそもそも選択肢を用意しているかです。

同じ仕事、違うコア

どちらの構成も一巡で機密性と完全性を与え、関連データを認証します。だから VPN プロトコルはデータチャネルにこれらを使います。違いは内側にあります。AES-GCM はカウンタモードの AES ブロック暗号に GF(2^128) 上の多項式認証器を組み合わせたもので、ChaCha20-Poly1305 は 256 ビット鍵のストリーム暗号に別個の使い捨て認証器を組み合わせたものです。

運用上重要な点は共通です。どちらも nonce の再利用で致命的に破綻し、どちらも鍵ごとに nonce 空間の管理が必要で、どちらも間違ったものを認証する相手を直しません。AES-256-GCM と書かれたプロファイルは CHACHA20-POLY1305 と書かれたものより安全ではなく、実装が正しければどちらも強いのです。

AES-GCM が勝つところ

AES にはほとんどの現代的な CPU に専用命令があります。x86 の AES-NI、ARMv8 の暗号拡張、そして最近の POWER や RISC-V の設計における同等のものです。これらがあれば GCM はサイクル当たり複数ブロックを並列に処理し、ソフトウェア実装は無関係になります。サーバー、デスクトップ、現在のスマートフォンではこれが普通の状況であり、データセンターで AES を使えという助言が妥当な既定値である理由でもあります。

問題は二番目の場合です。専用命令がなければソフトウェアの AES は遅く、テーブル駆動のソフトウェア実装はキャッシュタイミング問題の長い歴史を持つものです。ホストがゲストに AES のフラグを見せない仮想マシンで動く VPN 集約装置はまさにこの場合で、ホストの CPU には機能があるため見落とされがちです。

CPU が何を支援するかではなく、プロセスが実際に何を見ているかを確認してください。Linux なら grep -o aes /proc/cpuinfo | head -1、あるいはハイパーバイザーの CPU モデルにおける同等の機能フラグです。

ChaCha20-Poly1305 が勝つところ

ChaCha20 は可搬性のあるソフトウェアで速いのは、加算、回転、XOR だけを使い、実装が設計上、秘密に依存するテーブル参照を避けるからです。AES 高速化のない機器ではこれは実質的な利点であり、WireGuard がこれを選んだ理由でもあります。WireGuard プロトコルの説明は ChaCha20-Poly1305 を代替なしのデータ暗号として挙げています。

その一つの選択は有用なことを語ります。AES が高速化されるハードウェアでは、WireGuard は AES-GCM に比べてスループットをいくらか譲り、作者たちはスマートフォン、家庭用ルーター、コンテナホストでの予測可能な挙動と引き換えにそれを受け入れました。あなたの群れが主に小さな ARM の箱なら、その交換はあなたに有利です。

逆の場合は多忙な x86 集約装置で、そこでは AES-NI 付きの AES-GCM がより速くよく支えられた道であり、ChaCha20 はギガビット当たり測定できる CPU を費やします。どちらの構成も弱点ではありません。問題はあなたのハードウェアがどちらを安く実行するかです。

プロトコルが実際に選ばせてくれるもの

ProtocolWhat you get
WireGuardChaCha20-Poly1305 only; no negotiation
OpenVPN 2.5 and laterData channel negotiated from data-ciphers: AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305
IPsec / IKEv2AES-GCM as a combined-mode transform, or ChaCha20-Poly1305 where both peers implement it
OpenVPN control channelTLS decides; TLS 1.3 offers AES-GCM and ChaCha20-Poly1305 suites

OpenVPN の分割に注目してください。制御チャネルとデータチャネルは別々に交渉されます。だから TLS について見えるスイートは、ペイロードを守る暗号について何も語りません。セッションの要約は両方を報告し、二つのうち片方だけを読むのはよくある混乱の源です。

OpenVPN ではデータチャネルの暗号は両端の data-ciphers の一覧から来ます。サーバーの一覧とクライアントの一覧が交わらなければ、接続は data-ciphers-fallback が許すものへ後退するか、完全に失敗します。そしてその失敗はたいてい間違った層のせいにされます。両側に同じ一覧を置き、一覧の順序が守られたと仮定するのではなく、交渉された結果をログで確認してください。

配備についての三つの事実から決める

第一に、端点に AES 高速化はあるか。すべての相手にあるなら AES-GCM が安い選択で、保守された構成のほとんどで既定です。かなりの割合が小さなルーターや古いスマートフォンなら、ChaCha20-Poly1305 が群れの末尾を容量の限界にしないようにします。

第二に、プロトコルはそもそも選択肢を出すか。WireGuard では決定はあなたの代わりに済んでおり、有用な仕事は周囲の道具が黙って別のものを差し込んでいないか確かめることです。OpenVPN と IPsec では答えは設定の一行と、記録すべき交渉結果です。

第三に、両端は合意できるか。一方の相手が実装しない暗号は性能の判断ではなく、停止です。だから相手の一覧はどんなベンチマークよりも重要です。混在した群れには能力の交わりが必要で、最速の機械の好みではありません。

測るなら、機器、端点、負荷を同じにして一つのことだけを変えてください。異なる地域の二つのサーバーを比べる試験は経路を測るのであり暗号を測るのではありません。ノート PC の計測は、CPU のフラグが覆われたコンテナホストについて何も語りません。比べたうえで、実際にどの暗号が交渉されたかを書き留めてください。その記録はベンチマークより価値があります。

関連記事