量子安全のローカルトンネル：ポスト量子暗号に向けた開発スタックの準備

量子コンピューティングはセキュリティチームや標準化団体のロードマップ項目です。NISTは今日の公開鍵アルゴリズムの廃止予定日を提案しており、主要なCDNやOSはすでにデフォルトでポスト量子鍵交換を交渉しています。この移行であまり注目されていない部分の一つが、ローカル開発トンネルです。

開発者はトンネルを使ってlocalhostをWebhookプロバイダーやモバイルテストデバイス、ステージングビルドをレビューするクライアントに公開します。トンネルはTLSで保護されたパイプであり、他のTLS接続と同じ暗号学的リスクを引き継ぎます。また、APIキーやセッショントークン、実システムからコピーしたペイロードなど、後で読み取られたくない重要な情報も含まれることがあります。

このガイドでは、量子コンピュータがトンネル内の何を破壊できるか、何を破壊できないかについて解説します。また、今日の標準規格とTLS 1.3におけるハイブリッド鍵交換の仕組みについても触れます。さらに、既にポスト量子鍵交換をサポートしているトンネルツールと、そのパフォーマンスコストについても見ていきます。

---

1. トンネル内で実際にリスクにさらされているもの

トンネル接続の構造

トンネルには二つの部分があります：

1. パブリック側: ブラウザやモバイルアプリ、Webhook送信者がTLSを使ってトンネル提供者のパブリックエッジに接続します。
2. エージェント側: ノートパソコン上のクライアントデーモンが同じエッジに長時間接続を維持し、リクエストを多重化します。

各側はそれぞれ独自の暗号ハンドシェイクで保護されています。TLS 1.3では、セッションキーはエフェメラル（EC）DHE鍵交換、通常はX25519から生成されます。サーバーの証明書はRSAやECDSAの署名で検証されます。片側だけを保護するトンネルはもう一方を古典的なままにします。どちらの側も弱点になり得ます。

Shorのアルゴリズムが重要な理由

Shorのアルゴリズムは、大規模なフォールトトレラント量子コンピュータ上でRSA、有限体Diffie-Hellman、楕円曲線暗号（X25519やECDSAを含む）を破壊します。対称暗号（AES-256やChaCha20）は弱点ではないため、トンネルの大量暗号化部分は置き換える必要がありません。

現時点でこれを実現できるマシンは存在しませんが、その必要性の見積もりは短縮しています。2019年、Craig GidneyとMartin EkeråはRSA-2048の因数分解には約2000万のノイジーキュービットが必要と推定しました。2025年5月、Gidneyは修正見積もりとして、100万未満のノイジーキュービットと1週間未満の実行時間を示しました。これらは未だ実現されていないリソースの見積もりですが、計画の見通しが短縮された理由です。

Store-now-decrypt-later (SNDL)

SNDLは、暗号化されたトラフィックを今記録し、将来量子コンピュータが利用可能になったときに復号することを意味します。政府の移行ガイダンスやNISTの移行案は、これを理由に鍵交換を最初に移行すべきとしています。特に開発者トンネルのトラフィックをアーカイブしている具体的な事例は記録されていませんが、リスクの観点から、古典的な鍵交換だけで保護されたセッションは、量子コンピュータが登場すればいつでも露出します。

これは主に鍵交換に関係します。署名や証明書はSNDLの対象ではありません。なぜなら、署名の偽造は接続中にしか役立たないからです。だからこそ、業界では認証よりも先に鍵交換が移行されてきました。

あなたのトンネルにとってこれが重要かどうかは、何が通過し、どれだけ秘密を保持し続ける必要があるかによります。Webhookペイロードに含まれるライブ資格情報や、テスト環境にコピーされた顧客データ、未公開のソースコードなどは、10年後も敏感な情報であり続ける可能性があります。

---

2. 標準規格：2026年10月時点の状況

2024年8月13日、NISTは最初の3つのポスト量子標準を発表しました：

標準	アルゴリズム	出所	目的
FIPS 203	ML-KEM	CRYSTALS-Kyber	鍵カプセル化（鍵交換）
FIPS 204	ML-DSA	CRYSTALS-Dilithium	デジタル署名
FIPS 205	SLH-DSA	SPHINCS+	ハッシュベースのデジタル署名

さらに2つの項目が進行中です。FalconをベースにしたFN-DSAはFIPS 206で規定されており、まだドラフト段階です。最終化は2026年後半または2027年前半を見込んでいます。2025年3月、NISTはHQC（コードベースのKEM）をML-KEMのバックアップとして選定しました。

ML-KEMのセキュリティは、構造化格子上のエラー問題の難しさに基づいています。TLS、SSH、VPNの導入に採用されているアルゴリズムです。

移行スケジュール

NISTのドラフト報告書IR 8547（2024年11月12日公開）は、2030年以降にRSA-2048やP-256 ECCなどの量子脆弱な公開鍵アルゴリズムの廃止を提案しています。これらは提案段階ですが、連邦政策や調達方針はこれらの日時に基づいています。NSAのCNSA 2.0スイートは、より早いマイルストーンを設定し、ML-KEM-1024とML-DSA-87を推奨しています。

---

3. なぜハイブリッド鍵交換が一般的なのか

ハイブリッド鍵交換は、古典的な交換（X25519）とポスト量子（ML-KEM-768）を同じハンドシェイクで実行し、両方から導出したセッションキーを使用します。攻撃者は両方を破る必要があります。これにより、次の二つの失敗モードをカバーします：

• 新しいポスト量子コードや数学に見つかった欠陥
• 将来の量子破壊による古典的楕円曲線の脆弱性

政府間の見解は一致していません：

• ドイツのBSIとフランスのANSSIは、古典的アルゴリズムとのハイブリッドを必須または強く推奨します。
• NSAは、国の安全保障システムにおいてハイブリッドを必要としません。相互運用性のために受け入れ、規定された日付までにCNSA 2.0純粋なアルゴリズムを目指します。
• NISTは、ハイブリッドを義務付けるのではなく、鍵確立方式の組み合わせに関するガイダンス（SP 800-227）を策定中です。

したがって、TLSを中心に公開インターネットではハイブリッドが主流ですが、必須ではありません。

TLS 1.3での仕組み

広く使われているハイブリッドグループはX25519MLKEM768です。これはIETFのインターネットドラフトdraft-ietf-tls-ecdhe-mlkemで定義されており、執筆時点ではまだドラフト（改訂版05、2026年5月）です。このドラフトでは、SecP256r1MLKEM768やSecP384r1MLKEM1024も定義されています。交換の流れは次の通りです：

1. クライアントの鍵共有はML-KEM-768のカプセル化鍵と、そのエフェメラルX25519公開鍵です。
2. サーバーの鍵共有はML-KEMの暗号文と、そのエフェメラルX25519公開鍵です。
3. 両者はML-KEMの共有秘密とX25519の共有秘密を計算し、それらを連結して、通常のTLS 1.3の鍵スケジュールに入力します。

鍵スケジュールは変更されていないため、その後のハンドシェイクや対称レコード暗号化は従来通りです。

サイズ

鍵交換	クライアント側の鍵共有	サーバー側の鍵共有
X25519	32バイト	32バイト
ML-KEM-768（カプセル化鍵 / 暗号文）	1,184バイト	1,088バイト
X25519MLKEM768（ハイブリッド）	1,216バイト	1,120バイト

従来のX25519と比較して、ハイブリッドは2,272バイト（約2.2 KiB）の追加となります。

---

4. これがトンネルツールに与える影響

ポスト量子対応はツールによって大きく異なるため、各ツールを個別に確認してください。

SSHリバーストンネル。 OpenSSH 10.0（2025年4月リリース）では、ハイブリッドmlkem768x25519-sha256がデフォルトの鍵交換になっています。ssh -Rを使ってローカルポートを公開している場合、最新のOpenSSHを実行していれば、すでにポスト量子ハイブリッドです。バージョン10.1では、非ポスト量子の鍵交換を使った場合に警告が表示されます。

Cloudflare Tunnel。 Cloudflareは2022年10月にcloudflaredのポスト量子モードを導入し、ドラフトKyberハイブリッドを使用しています。これを有効にすると、cloudflaredは最終標準にフォールバックしません。リリース時点では、トンネルの制御接続や認証はまだポスト量子ではありませんでしたが、2026年2月までに60%以上のクライアントトラフィックがポスト量子暗号化を使用していると報告されています（2024年初頭は3%未満）。詳細な挙動はCloudflareのドキュメントを確認してください。

WireGuardベースのツール。 Tailscaleのドキュメントによると、そのWireGuard実装はポスト量子ではありません。WireGuardは意図的にプロトコルの柔軟性を避けているため、ML-KEMを単純に差し替えることはできません。WireGuardを使ったツールについては、ベンダーに計画を確認してください。

Goで構築または実行するツール。 Go 1.24（2025年2月リリース）では、crypto/tlsでConfig.CurvePreferencesがnilの場合、X25519MLKEM768がデフォルトで有効になっています。Go 1.24以降で構築されたトンネルクライアントやエッジは、コードの変更なしでハイブリッドグループを交渉します。Kubernetes v1.33もこれを自動的に採用しています。GODEBUG=tlsmlkem=0を設定すると無効化できますが、これはバグのある中間装置やサーバーが大きなハンドシェイクを処理できない場合の対処法です。

その他のプロバイダー。 公開ドキュメントでポスト量子鍵交換をサポートしていると確認できるサービスは少数です。利用している場合は、ベンダーにパブリック側とエージェント側の両方がハイブリッドグループを交渉しているか、フォールバック時の挙動について問い合わせてください。

確認すべきアーキテクチャポイント

プロバイダーがTLSをエッジで終了させる場合、パブリック側とエージェント側は別のTLSセッションです。一方だけのポスト量子保護では十分ではありません。両方を保護していても、エッジは平文を見ています。非常に敏感なデータについては、トンネル内のエンドツーエンド暗号化の方が鍵交換の選択よりも重要です。

---

5. GoでのハイブリッドTLS設定

Go 1.24以降では、デフォルトですでにハイブリッドグループを優先しています。明示的に設定したい場合は、次のようにします：

package main

import (
	"crypto/tls"
	"log"
	"net/http"
)

func newServer() *http.Server {
	cfg := &tls.Config{
		MinVersion: tls.VersionTLS13,
		// ポスト量子ハイブリッドを優先しつつ、古いクライアントも接続可能にするため
		CurvePreferences: []tls.CurveID{
			tls.X25519MLKEM768,
			tls.X25519,
		},
	}
	return &http.Server{
		Addr:      ":443",
		TLSConfig: cfg,
	}
}

func main() {
	srv := newServer()
	log.Fatal(srv.ListenAndServeTLS("cert.pem", "key.pem"))
}

注意点

• TLS 1.3の暗号スイートはGoのcrypto/tlsでは設定できないため、CipherSuitesのリストは不要です。鍵交換グループがポスト量子保護を決定します。
• tls.X25519をフォールバックに残すと、古いクライアントも接続できますが、ダウングレードが可能になります。両端を制御できる場合は、フォールバックを廃止してハイブリッドを必須にするのが良いです。Cloudflareも--post-quantumフラグでこれを採用しています。

ハイブリッドグループはTLS 1.3にのみ適用されます。TLS 1.2を交渉したクライアントは純粋な古典的ハンドシェイクとなるため、MinVersion: tls.VersionTLS13が重要です。

---

6. パフォーマンス：測定結果

ハイブリッド鍵交換のコストは、ほぼハンドシェイクの追加バイト数に由来し、計算コストはほとんどありません。以下の数値は大規模展開から得られたものであり、トンネル固有のベンチマークではありません。参考値として扱ってください。

• ハンドシェイク遅延。 ChromeのエンジニアはIETFのメーリングリストで、KyberをTLSハンドシェイクに追加すると、デスクトップで約4%、Androidで約9%の遅延増加が中央値で報告されました。Cloudflareの測定では、サーバー応答に1 KB追加ごとにHTTPSハンドシェイクの中央値遅延が約1.5%増加しました。これらはハンドシェイクのみの増加率であり、ページロードやリクエスト全体の遅延ではありません。
• 中間装置やサーバーの互換性。 大きなClientHelloは、不適切に書かれたサーバーや中間装置のバグを引き起こす可能性があります。Cloudflareの調査では、送信されたポスト量子鍵共有を受け取った場合にハンドシェイクに失敗したオリジンは約0.34%でした。tlsmlkem=0は、バグのあるサーバーが大きなレコードを処理できない場合の回避策です。
• リトライコスト。 クライアントがサポートするグループを誤認した場合、TLS 1.3は追加のラウンドトリップ（HelloRetryRequest）を必要とします。Cloudflareの調査では、オリジンの優先度を測定し、リトライを約52%から3.7%に削減し、p90のハンドシェイク遅延から150 ms以上を削減しました。
• ハンドシェイク後。 大量データは従来通りの対称暗号（AES-GCMやChaCha20-Poly1305）で保護されるため、バイトあたりのスループットは変わりません。AWSのハイブリッドTLSの分析では、追加コストは接続ごとに一度だけ支払われ、セッション全体にわたって償却されると指摘しています。コネクションプールを使えば、その影響はさらに軽減されます。

トンネルの場合、エージェント側は長寿命の多重化された接続であることが多いため、ハンドシェイクコストは一度だけです。パブリック側は新しい接続ごとにコストがかかりますが、Webhook送信者やブラウザは接続を再利用するため、頻繁には支払わなくて済みます。特定のミリ秒単位の測定結果は持っていませんが、ハイブリッドグループのオン・オフで自分のトンネルを計測してみることを推奨します。

---

7. 実践的なステップ

1. トンネルの棚卸し。 利用しているツール（SSH、商用プロバイダー、自分で運用しているエージェント）をリストアップし、各ツールのドキュメントでML-KEMやX25519MLKEM768のサポート状況を確認します。
2. ハイブリッドをデフォルトとするツールを優先。 OpenSSH 10.0以降やGo 1.24以降はすでに対応済みです。クライアントとサーバーをアップデートし、手動設定を避けましょう。
3. 確認を怠らない。 OpenSSLやパケットキャプチャを使って実際のハンドシェイクを観察し、交渉されたグループがハイブリッドであることを確認します。X25519へのサイレントフォールバックは問題です。
4. 両端を制御できる場合はTLS 1.3のみを要求。 TLS 1.2は古典的なハンドシェイクです。
5. 秘密情報の運用は暗号化だけに頼らない。 本番用資格情報はローカル環境に置かず、短命のスコープ付きトークンを使い、実顧客データをトンネル経由で送信しない。これにより、記録されたトラフィックの被害を限定できます。
6. 認証は別途計画。 ポスト量子証明書や署名は鍵交換よりも移行が難しく、まだ広く展開されていません。短命証明書は良い習慣ですが、store-now-decrypt-laterには効果がありません。
7. 暗号の柔軟性を維持。 FN-DSAやHQCは標準化の途中であり、TLSのハイブリッドもインターネットドラフトです。設定やアップデートでアルゴリズムを変更できるツールを選びましょう。

---

結論

ローカルトンネルの実用的な状況は、見出しが示すほど悲観的ではありません。ポスト量子鍵交換は標準化され、OpenSSH 10やGo 1.24などの広く使われているソフトウェアでデフォルトで提供され、遅延コストも控えめです。残る作業は、検証とツール選定です。両側のハイブリッドグループ交渉を確認し、秘密情報をトンネル内に置かず、ポスト量子認証を次のステップと考えましょう。

---

参考資料

• NIST FIPS 203, 204, 205（2024年8月13日最終版）とFIPS 206・HQCの状況： Encryption Consulting – Decoding NIST PQC Standards; NIST PQC overview slides
• NIST IR 8547のタイムライン（2030年廃止、2035年禁止、提案）： Encryption Consulting – NIST IR 8547 Explained
• TLSハイブリッド鍵交換ドラフト： draft-ietf-tls-ecdhe-mlkem
• ML-KEM-768のサイズ： facil.io ML-KEM-768リファレンス
• ハイブリッドポリシーの立場（NSA、BSI、ANSSI）： PostQuantum.com – Global PQC Requirements; PQShield – CNSA 2.0 update
• Go 1.24のデフォルトハイブリッド： Go GODEBUGドキュメント; Kubernetesブログ – PQC in Kubernetes
• OpenSSH 10.0リリースノート： openssh.com
• Cloudflare Tunnelのポスト量子モード： Introducing post-quantum Cloudflare Tunnel
• Cloudflareの採用データ： Bringing more transparency to post-quantum usage
• TailscaleとWireGuard： Tailscale post-quantum cryptography documentation
• ハンドシェイク遅延の測定データ： IETF TLSリスト – ChromeとCloudflareの測定; AWS Security Blog – パフォーマンスのハイブリッドポスト量子TLS; InfoQ – Cloudflare origin TLSの設定
• RSA-2048のリソース見積もり： Gidney, “How to factor 2048 bit RSA integers with less than a million noisy qubits”