定義（用語カード）： ChaCha20-Poly1305は、ChaCha20ストリーム暗号とPoly1305メッセージ認証コードを組み合わせた、関連データを伴う認証付き暗号化（AEAD）構成である。256ビット鍵でトラフィックを暗号化し、128ビットの認証タグを付与することで、受信側は同じ暗号操作の中で改ざんを検出できる。
VPNアプリがWireGuardやTLS暗号スイートの横に「ChaCha20-Poly1305」と記載している場合、それはハンドシェイク後にパケットペイロードを実際に保護するアルゴリズムの名前である。その名称を理解することは、マーケティングスローガンを暗記することより重要だ。ChaCha20-Poly1305はそれ自体がVPNプロトコルではなく、AESの劣った代替でもない。IETFプロトコル向けに標準化された現代のAEAD暗号であり、WireGuard、TLS、SSH、IPsecで広く導入されている。
名称の由来
Daniel J. Bernsteinは、高速なソフトウェア用プリミティブとしてPoly1305（2005年）とChaCha（2008年）を設計した。IETFはその後、特定のAEADの組み合わせを RFC 8439 （RFC 7539 を廃止）：ChaCha20 は平文と XOR されるキーストリームを生成し、Poly1305 は暗号文と関連データを認証します。この構成により、暗号文は固定の 16 バイトタグ分だけ長くなります。
次の資料によると ChaCha20-Poly1305 Wikipedia の概要このアルゴリズムは 256 ビットの鍵と 96 ビットの nonce を取り、AES-GCM でおなじみの encrypt-then-MAC 構造を踏襲し、IPsec、SSH、TLS 1.2/1.3、DTLS、WireGuard で使用されています。この広範な採用こそ、同じ暗号名が一般向け VPN クライアントと企業向けゲートウェイの両方に現れる理由です。
ChaCha20 の暗号化の仕組み
ChaCha20 はストリーム暗号です。AES のようにデータを 128 ビットのブロックに分割しません。代わりに、鍵、nonce、ブロックカウンタを、加算、XOR、ビット回転のみを用いた 20 ラウンドで 64 バイトのキーストリームブロックへと展開します。キーストリームは平文と XOR されて暗号文になります。復号は同じキーストリームとの同じ XOR です。
Proton の ChaCha20 解説 VPN 利用者向けの実務的な要点をまとめています。ChaCha20 は通常のソフトウェアでも高速に動作するよう設計されており、スマートフォン、古い CPU、AES ハードウェアアクセラレーションのないデバイスに有利です。AES-NI や ARM の暗号拡張がある場合は AES が勝ることが多く、純粋なソフトウェアで一貫したタイミング特性を保ちながら暗号化する必要がある場合は ChaCha20 が勝ることが多いです。
Poly1305 が加えるもの
暗号化だけでは、攻撃者が転送中にビットを反転させることを防げません。Poly1305 はワンタイムのメッセージ認証コードであり、暗号文（および関連データ）に対して 16 バイトのタグを生成します。RFC 8439 の AEAD 構成では、最初の ChaCha20 ブロックがワンタイムの Poly1305 鍵を生成し、後続ブロックがペイロードを暗号化します。タグの検証に失敗した場合、平文を開示せずにパケットを破棄しなければなりません。
この「1 つの API で暗号化してから認証する」モデルが AEAD の意味です。AES-GCM も内部実装は異なりますが同じ役割を果たします。セキュリティ分析者は、正しく実装された ChaCha20-Poly1305 と AES-256-GCM を、標準的な前提のもとで同等の機密性と完全性を提供するものとして扱います。ただし、同一の鍵に対して nonce を繰り返してはなりません。
WireGuardとモバイルスタックが重視する理由
WireGuardが公開している暗号設計では、転送用暗号がChaCha20-Poly1305に固定されています。クラシックなWireGuardにはAESを切り替えるユーザー向けトグルはありません。この選択によりプロトコルは小さく監査しやすく保たれます。AEADは1つ、鍵交換ファミリーは1つ、設定面は最小限です。OpenVPNとIKEv2/IPsecは複数の暗号を交渉でき、ライブラリと対向が対応していればChaCha20-Poly1305も含みます。そのためこのアルゴリズム名はWireGuard以外でも現れます。
モバイルネットワークや電池制約のある端末では、ソフトウェア実装に適した暗号が重要です。RFC 8439の性能付録で引用された過去のTLS測定では、AES加速のないスマートフォン上でChaCha20-Poly1305がAES-GCMを上回り、AES-NIを備えたサーバーではAES-GCMが優位でした。2026年には多くのスマートフォンが暗号拡張を備えていますが、ソフトウェア向きの設計は依然として実装リスクを下げ、混在した端末群でもスループットを予測しやすくします。
ChaCha20対AES：本当に重要なトレードオフ
- 暗号の種類： ChaCha20はストリーム暗号です。AESはブロック暗号で、AEADとしては通常GCMモードで使われます。
- ハードウェア： AESはAES-NI／暗号拡張を持つCPUで通常優勢です。ChaCha20は純粋なソフトウェア実装で通常優勢です。
- タイミングサイドチャネル： ChaCha20の加算・回転・XOR設計は、一部のAESテーブル方式のソフトウェア実装よりも、キャッシュタイミングの落とし穴を避けて実装しやすいと広く見なされています。
- ナンスの規律： GCMもChaCha20-Poly1305も、(鍵, ナンス)の組を再利用すると壊滅的に破綻します。プロトコルは一意性を保証しなければなりません。WireGuardはパケットカウンタを使い、TLSはレコードごとに新しい鍵とナンスを導出します。
- コンプライアンス上の馴染み: 企業のチェックリストでは今でも AES-256 の方がよく名前が挙がります。それは組織的な慣習であり、標準化され正しく使われている ChaCha20-Poly1305 がより弱いという証拠ではありません。
ChaCha20-Poly1305 ではないもの
VPN プロトコルではありません。WireGuard、OpenVPN、IKEv2 の代替にもなりません。VPN を使っていることを隠したり、出口国を選んだり、ノーログ方針を強制したりもしません。それらは転送、ルーティング、運用者への信頼の問題です。ChaCha20-Poly1305 が答えるのは次の一点だけです。ピア同士がセッション鍵を共有したあと、盗聴者が読めたり黙って改ざんしたりできないよう、パケットをどう封じるか。
「耐量子」でもありません。AES-256-GCM と同様、対称暗号です。VPN におけるいわゆる harvest-now-decrypt-later（今収集して後で復号する）の懸念は、ハンドシェイクの鍵交換（現在は ECDH、ハイブリッド ML-KEM の導入が現れつつある）に向けられており、ChaCha20 自体を急に廃することではありません。耐量子 VPN という主張は、ハンドシェイクと認証についての発言として扱い、ChaCha20 を別のバルク暗号に置き換える話としては扱わないでください。
読者向けの実践チェックリスト
- クライアントに WireGuard と表示されているなら、データチャネルでは設計どおり ChaCha20-Poly1305 が使われると考えてください。
- クライアントに OpenVPN または IKEv2 と表示されているなら、ログまたは詳細設定で交渉された暗号を確認してください。ChaCha20-Poly1305 は AES-GCM と並んで利用できる場合があります。
- 「軍事級」といった形容詞を追わないでください。現行の RFC と維持されているクライアントに文書化された AEAD スイートを優先してください。
- 強力な AEAD でも、使い回したパスワード、フィッシングページ、トンネル外の DNS 漏洩は直せないことを忘れないでください。
要するに、ChaCha20-Poly1305 は今日の VPN および HTTPS トラフィックの多くを支える AEAD の主力です。定義を学び、nonce の規則を知り、プロトコルの選択と運用者の方針は、設定画面に出るバルク暗号の名前とは別の問題として扱ってください。