この記事は「PQC Advent Calendar 2025」の 11日目です。
この記事はAIによって生成されたコンテンツを含みます。
PQCにおける「ハイブリッド暗号」とは？
みなさん「ハイブリッド暗号」と聞いて何を思い浮かべますでしょうか？
TLSの中ではセッションを張る際に、共通鍵を公開鍵でラップして通信相手に送る方法のことを指します。
また耐量子計算機暗号(PQC)の議論においては、従来の暗号アルゴリズムとPQCの併用を指しますが、技術領域に応じて併用の目的や実装が異なります。
本記事では、PQCの中で「ハイブリッド暗号」という言葉の定義と、その目的・実装について紹介したいと思います。
PQCの文脈におけるハイブリッド暗号としては、大きく二つに分かれます。
- TLSのハイブリッド
- TLSの鍵合意でECDHとPQC‑KEMの両方使用したマスターシークレットを作成する。
- ハイブリッド証明書
- PQCと従来の暗号を併用した証明書を作成する
今回の記事では、TLSのハイブリッド暗号について深掘りさせていただきます。
TLSのハイブリッド暗号（PQC＋従来の暗号アルゴリズムでマスターシークレット生成）
IETF TLS WG のドラフトは、複数の鍵交換アルゴリズムの結果（共有秘密）を結合し、最終のハンドシェイク秘密としてTLS 1.3の鍵スケジュールに投入する構成を定義します。代表例はX25519MLKEM768（X25519＋ML‑KEM‑768）です。
ClientHello の supported_groups にハイブリッドグループ（例：X25519MLKEM768）を載せ、KeyShare で連結キーシェア（X25519公開鍵＋ML‑KEM公開鍵）を送ります。
ServerHello 側で、それぞれからX25519共有秘密とML‑KEM共有秘密を得て連結し、マスターシークレットとして作成した上で、マスターシークレットを用いてセッション鍵などの暗号化に必要な鍵を作成します。
https://www.netmeister.org/blog/tls-hybrid-kex.html
上記の実装を行うことで、従来の暗号アルゴリズムの危殆化だけでなく、PQC(ML-KEM)が危殆化した時にも通信の内容が解読できないセッションを形成することが可能となります。
実装・デプロイの最新動向
TLSのハイブリッド暗号はに関する実装はでしょうか
標準化途中ではありますが、多くのベンダーが実装を開始しています。
Chrome は X25519Kyber768 を バージョン116で導入、ML‑KEM（標準版）移行に伴いコードポイントを 0x11EC に更新（Chrome 131 以降）。
Cloudflareはエッジ／オリジン間を含めてハイブリッドKEXを展開。
OpenSSL 3系＋OQS ProviderはTLS1.3におけるハイブリッドKEMをサポート
OpenJDKも JEP 527 としてTLS 1.3ハイブリッドKEX（X25519/ML‑KEM）導入を計画。
まとめ
ハイブリッドは“橋渡し”：古典とPQCの同時併用で、安全と互換性の両立を図る。だが同じ用語が層によって意味を変えるため、TLSのハイブリッドKEXと証明書のハイブリッド／コンポジット／マルチ／カメレオンを区別して議論しよう。
実務では：TLS側のハイブリッドKEXを先に入れつつ、PKI側はユースケースに応じた証明書戦略を選択。互換性テストとサイズ設計を抜きに語れない。 [netmeister.org], [chromium.org]