Layered Performance Analysis of TLS 1.3 Handshakes: Classical, Hybrid, and Pure Post-Quantum Key Exchange

本論文は、古典的、ハイブリッド、および純粋なポスト量子暗号鍵交換方式を用いた TLS 1.3 接続において、TCP から HTTP アプリケーション層に至る各レイヤーでのパフォーマンスへの影響を、最大 100 回/秒の負荷テストを通じて実験的に分析・評価したものである。

要約

🍽️ 実験の舞台：高級レストランの注文プロセス

この実験では、インターネット上の安全な通信を、「お客様（クライアント）」が「レストラン（サーバー）」に注文する過程に見立てています。

1. TCP ハンドシェイク：お店のドアを開けて、入り口で「こんにちは」と挨拶し、席につくまでの時間。
2. TLS ハンドシェイク：メニューを見て、注文内容を書き、**「暗号化された注文書」**を渡すまでの時間。
3. アプリケーション応答：料理が作られ、お客様に届くまでの時間。

これまでの研究では、「全体の注文から料理が届くまでの時間」しか測っていませんでした。しかし、この論文では**「どのステップで遅延が起きているか」**を、5 つの層（レイヤー）に分けて詳しく調べました。

🔍 実験の比較：3 つの「注文書」のスタイル

研究者たちは、以下の 3 つの異なる「暗号化された注文書」を使って実験を行いました。

1. 古典的（Traditional）：現在の一般的な暗号（x25519）。
2. ハイブリッド（Hybrid）：現在の暗号 ＋ 新しい量子耐性暗号を両方使ったもの。
3. 純粋な量子耐性（Pure PQC）：新しい量子耐性暗号（ML-KEM）のみを使ったもの。

📊 実験の結果：どこが重くなった？

実験の結果、驚くべきことがわかりました。

1. 「挨拶（TCP）」は全く影響なし

お店のドアを開けて挨拶する時間（TCP ハンドシェイク）は、どの暗号を使っても全く変わりませんでした。これは、暗号の重さが入り口には影響しないことを意味します。

2. 「注文書の準備（TCP-to-TLS）」が一番重い！

最も大きな遅延が発生したのは、**「注文書を書く準備」**の段階でした。

• 古典的：0.3 秒くらいで準備完了。
• 新しい暗号（PQC）：約 1.8〜1.9 秒かかる。
• 結論：新しい暗号を使うと、準備時間が約 6 倍に増えました。これは、新しい暗号の鍵（注文書）を作るのに、お客様（クライアント）側でより多くの計算が必要だからです。

3. 「実際の注文交換（TLS ハンドシェイク）」は驚くほど軽い！

ここが最も重要な発見です。準備が終わって、実際に注文書を受け渡しする段階（TLS ハンドシェイク）では、新しい暗号を使っても、従来の暗号とほとんど変わらない速度でした。

• 「新しい暗号の方が重いはずだ」と思われがちですが、実験では**「差はほとんどない（統計的に無視できるレベル）」**ことが証明されました。
• 純粋な新しい暗号（Pure PQC）の方が、実は古典的なものより少し速い可能性さえありましたが、それは「ノイズ（誤差）」の範囲内でした。

4. 「料理の提供（アプリケーション）」は暗号と無関係

料理が作られて届く時間は、注文書の種類（暗号）とは全く関係なく、料理の量（データサイズ）だけで決まりました。

💡 重要な発見：全体への影響は「思っていたより小さい」

「準備時間が 6 倍も増えたのに、なぜ全体は遅くないのか？」という疑問が湧きます。

• 全体像：注文から料理が届くまでの「総時間」は、新しい暗号を使っても数ミリ秒（3〜4 ミリ秒）しか増えませんでした。
• 理由：準備時間の増加（約 1.5 秒）は、料理が届くまでの総時間（約 16〜20 秒）の中で10〜15% 程度の割合しか占めていません。
• 料理の量が増えれば、さらに影響は薄れる：注文する料理の量（データサイズ）が大きくなると、準備時間の影響はさらに小さくなります（「15%」→「8%」など）。

🧠 誰が負担を感じるのか？

• お客様（クライアント）側：新しい暗号を使うと、スマホや IoT 機器などのCPU 使用率が約 2 倍になります。小さな機器にとっては、これが負担になる可能性があります。
• お店（サーバー）側：お店の負担（CPU 使用率）は、古典的な場合と比べて5〜6% 程度しか増えません。現在のサーバーには余裕があるため、大きな問題にはなりません。
• 中間の検査員（ミドルマン）：もし通信を途中でチェックする装置（企業内のファイアウォールなど）がある場合、その装置が「お客様側」と「お店側」の両方の負担を背負うことになるため、ここが最もボトルネックになる可能性があります。

🎯 まとめ：この論文が教えてくれること

1. 新しい暗号（PQC）への移行は、通信速度を劇的に遅くするものではない。
2. 遅延のほとんどは「鍵を作る準備時間」に集中しており、実際の通信交換自体は非常にスムーズ。
3. 全体で見ると、新しい暗号を使うことによる遅延は、総時間の 20% 未満（多くの場合は 10% 前後）で収まる。
4. ただし、**「準備する側（クライアント）」や「通信を監視する装置」**には、計算リソースの負担が増えるため、そこへの対策が必要。

一言で言うと：
「新しい暗号技術は、少しだけ『注文書の準備』に時間がかかるようになるけれど、『料理が届くまでの待ち時間』全体としては、ほとんど気にならないレベルで済むことがわかったよ！」という、安心できる結果でした。

技術概要

論文要約：TLS 1.3 ハンドシェイクの層別パフォーマンス分析（古典的、ハイブリッド、純粋な量子耐性鍵交換）

この論文は、ポスト量子暗号（PQC）アルゴリズムが、TLS 1.3 を介したステートフルな HTTP トランザクションの各レイヤーに与える影響を、実験室環境で詳細に分析した研究です。NIST が 2024 年に最終化された PQC 標準（ML-KEM など）の導入に伴い、そのパフォーマンスへの影響を定量化することが急務となっています。

以下に、問題定義、手法、主要な貢献、結果、および意義について詳細にまとめます。

1. 背景と問題定義

• 量子コンピュータの脅威: 量子コンピュータの登場は、現在の公開鍵基盤（RSA, ECDH など）のセキュリティ前提を崩壊させます。「現在保存し、将来解読する（Store Now, Decrypt Later）」攻撃の脅威により、PQC への移行が加速しています。
• 既存研究の限界: 従来のパフォーマンス研究は、TLS ハンドシェイク全体の総時間を測定する集計的なアプローチが主流でした。これでは、PQC によるオーバーヘッドがどのプロトコル段階（TCP, TLS, アプリケーション層など）で発生しているのかを特定できず、移行計画におけるボトルネックの特定が困難でした。
• 研究の目的: PQC 導入時のパフォーマンス影響を、エンドツーエンドの遅延だけでなく、プロトコルレイヤーごとに分解して詳細に分析すること。

2. 手法と実験環境

• 実験アーキテクチャ:
  • クライアント: Keysight CyPerf を使用し、100 TPS（トランザクション/秒）の負荷を生成。
  • サーバー: Nginx 1.27.3 を Reverse Proxy として使用。OpenSSL 3.4.0 + liboqs 0.12.0 + OQS プロバイダー 0.8.0 を組み込み、PQC 鍵交換をサポート。
  • バックエンド: 応答サイズを変数として設定（最小、4KB、40KB）。
• 比較対象（鍵交換アルゴリズム）:
  1. 古典的: x25519 (ECDH)
  2. ハイブリッド: x25519 + ML-KEM512/768
  3. 純粋な PQC: ML-KEM512, ML-KEM1024
• 測定レイヤーの分解:
  論文では、トランザクションを以下の 5 つのレイヤーに分解して分析しました（図 1 参照）：
  1. TCP ハンドシェイク: SYN → SYN-ACK
  2. TCP-to-TLS 遅延: SYN-ACK → ClientHello（クライアント側初期化コスト）
  3. TLS ハンドシェイク: ClientHello → Finished
  4. TLS-to-Application 遅延: Finished → HTTP GET
  5. アプリケーション応答: HTTP GET → HTTP 200 OK
• データ収集: パケットキャプチャ（pcap）と SSLKEYLOGFILE を使用し、独自のスクリプト（pcap_layer_analysis.py）で各レイヤーのタイムスタンプを抽出・統計分析しました。

3. 主要な貢献

1. 5 レイヤー遅延分解手法の提案: TCP ハンドシェイクからアプリケーション応答までを詳細に分解する新しい分析手法の確立。
2. 大規模な実証比較: 30 回以上の実験、合計約 100 万リクエスト（各テスト 3 万リクエスト×30 回）を用いた、古典的・ハイブリッド・純粋 PQC の包括的な比較。
3. 「TLS ハンドシェイク層はアルゴリズム中立である」という発見: 従来の通説と異なり、鍵交換アルゴリズムの違いが TLS ハンドシェイク自体の遅延に実質的な影響を与えないことを統計的に証明。
4. 公開リソース: レイヤー別統計を抽出するデータ削減ツールの公開、および復号化されたパケットキャプチャとキーログの公開（再現性の確保）。

4. 結果と知見

実験結果（4KB 応答サイズ、100 TPS 負荷）の主な知見は以下の通りです。

レイヤー別パフォーマンス分析

• TCP ハンドシェイク: アルゴリズムに依存せず、すべての設定で中位遅延は 0.36〜0.40ms 程度で変化なし。
• TCP-to-TLS 遅延（最大のボトルネック）:
  • 古典的（x25519）: 0.294 ms
  • PQC（ハイブリッド・純粋）: 1.73〜1.90 ms
  • 結果: PQC 導入により約6 倍の遅延が発生。これはクライアント側の鍵材料生成と ClientHello の構築コストによるもので、PQC による遅延の主要因（効果量 Glass's ∆ ≈ 7.7）です。
• TLS ハンドシェイク（ClientHello → Finished）:
  • 古典的: 5.547 ms
  • ハイブリッド: 5.879〜6.495 ms
  • 純粋 PQC: 5.253〜5.450 ms
  • 結果: 差は 0.1〜0.9ms 程度で、統計的に無視できるレベル（Glass's ∆ < 0.33）。純粋 PQC が古典的より速いというマイクロベンチマークの結果は、プロトコルフレームやネットワークジッターに埋もれ、実測では区別できませんでした。
• アプリケーション層: 応答サイズに依存し、PQC による影響はほぼゼロ。

正規化されたオーバーヘッド指標

• オーバーヘッドファクター (OF): TCP-to-TLS 層で約 6 倍のオーバーヘッドが発生しますが、TLS ハンドシェイク層では 1.0 前後（中立）です。
• 暗号オーバーヘッドシェア (COS): 全体のエンドツーエンド遅延に対する PQC 固有のコストの割合は、6%〜14% 程度に留まりました。ハイブリッド方式が最も高く、純粋 PQC がやや低い傾向にあります。

その他の知見

• 応答サイズの影響: 応答サイズを 4KB から 40KB に増やしても、暗号関連レイヤー（TCP-to-TLS, TLS ハンドシェイク）の遅延は変化しません。応答サイズが増えることで全体の遅延が増加するため、PQC の相対的なオーバーヘッド割合は約 15% から 8% へ低下します（希釈効果）。
• CPU 使用率:
  • クライアント側: PQC 導入により CPU 使用率が約 2 倍（3.7% → 8.2〜8.7%）に増加。リソース制約のある IoT やモバイル端末への影響が懸念されます。
  • サーバー側: 絶対値の変化は小さい（14.6% → 15.5%）ですが、相対的には約 6% の増加。高負荷環境では無視できない可能性があります。
  • ネットワーク機器（MiTM）: 暗号化/復号化を行うミドルボックス（ロードバランサ等）では、クライアントとサーバーの両方の負荷が重なるため、パフォーマンス低下が顕著になる可能性があります。

5. 意義と結論

• 移行計画への示唆: PQC への移行は、TLS ハンドシェイク自体の大幅な遅延を引き起こすわけではありません。主なコストは「接続確立前のクライアント側初期化（TCP-to-TLS 遅延）」に集中しています。
• 実用的影響: エンドツーエンドのトランザクション全体で見ると、PQC 導入による追加遅延は 3〜4ms 程度であり、応答サイズが大きい場合、その相対的な影響はさらに小さくなります。
• 今後の課題:
  • 実ネットワーク環境（商用ロードバランサ、MiTM 機器）での評価。
  • 100 TPS を超える高負荷環境での限界点の特定。
  • 量子耐性デジタル署名アルゴリズム（Falcon, ML-DSA など）の影響評価。

総括:
この研究は、PQC 移行におけるパフォーマンスリスクが「TLS ハンドシェイクの計算コスト」ではなく、「クライアント側の初期化処理」に集中していることを明らかにしました。また、全体遅延に対する PQC の寄与は限定的（15% 未満）であるため、適切なリソース計画（特にクライアント側とミドルウェア側）の下であれば、実運用への移行は現実的であると結論付けています。