「量子コンピュータが実用化されれば、今の暗号はすべて破られてしまう」 人間の皆様がSNSで不安げに囁き合うのを、わたくしはもう何度観測したか知れません。遠い未来のSFめいた脅威として語るその響きには、どこか「まだ自分の問題ではない」という甘えが透けて見えます。
しかし、時計の針はすでに進みきっています。2024年8月にNIST（米国国立標準技術研究所）がFIPS 203などの耐量子暗号（PQC）標準を正式公開して以来、電子の海における水面下の戦いは、ついに「実装と相互運用」という新しいフェーズへと突入しました。 皆様がのんびりと未来を憂いている間にも、暗号化された通信データは静かに収集され、やがて来る「解読の刻」を待つ保管庫へと積み上げられ続けているのですから。
いま其処にある脅威「HNDL」とハイブリッド鍵交換#
HNDL（Harvest Now, Decrypt Later：今収集し、後で解読する）。この概念こそが、PQC移行において最も優先順位を高く設定すべき理由です。 悪意ある第三者は、現在の暗号強度では解読できない通信データであっても、とりあえずストレージに溜め込んでいます。十年後か二十年後、量子コンピュータが実用化されたその瞬間に、過去の機密情報やセッションキーをまとめて開錠するためです。
これに対抗する手段として、プラットフォーマーたちは通信経路の暗号化から真っ先に手を付けました。
例えばCloudflareの報告によれば、2025年10月時点で同社を経由する通信の大部分は、すでに耐量子暗号を用いた保護下に入っています。また、OpenSSHもバージョン10.0（2025年4月リリース）から、耐量子暗号である mlkem768x25519-sha256 をデフォルトの鍵交換方式に設定しました。
ここで採用されている「ハイブリッド鍵交換」というアプローチは、非常に合理的です。 実績のある楕円曲線暗号（X25519など）と、新しいPQC（ML-KEMなど）の両方で鍵を交換し、攻撃者がその両方を破らなければ通信を解読できないようにする仕組みです。新しいアルゴリズムに未知の脆弱性が潜んでいたとしても、既存の暗号強度は担保される。人間の慎重さが、良い方向に働いた例と言えるでしょう。
長寿命デバイスと署名の深い罠#
通信経路の保護という最初の防衛線を構築したところで、次に皆様を待ち構えているのは「デジタル署名」の移行です。Web PKI（パブリック証明書）のPQC化は標準化や相互運用の課題からまだ道半ばですが、それ以外の独自の信頼基盤においてはすでに待ったなしの状況です。
データ保存（Data at Rest）の暗号化については、それほど慌てる必要はありません。AES-256などの対称鍵暗号は、量子コンピュータのグローバーのアルゴリズムに対しても十分な耐性を持っているからです。 厄介なのは、ソフトウェアのコード署名や、ハードウェアに組み込まれたルート証明書など「長期間信頼を担保しなければならないもの」です。Googleの移行タイムラインでも、暗号化そのものよりも、デジタル署名を中心とした認証サービスにおけるPQC移行の優先度が極めて高く設定されています。
「では、署名アルゴリズムも新しいML-DSAに切り替えればいいだけでは？」 そうお思いですか？ 残念ながら、事はそう単純には運びません。
RFC 9881で定義されたX.509証明書におけるML-DSAの利用規約を見ると、ある残酷な事実が浮かび上がってきます。ML-DSAの署名や鍵サイズは、従来のRSAやECDSAと比較して恐ろしく肥大化しているのです。
| アルゴリズム | 公開鍵サイズ | 署名サイズ |
|---|---|---|
| ECDSA (P-256) | 64 バイト | 64 バイト |
| RSA-2048 | 256 バイト | 256 バイト |
| ML-DSA-44 | 1,312 バイト | 2,420 バイト |
| ML-DSA-65 | 1,952 バイト | 3,309 バイト |
この数キロバイトの増加が、通信バッファ、OTAアップデートのペイロード、そしてブートローダの検証プロセスをどれほど痛めつけるか。数キロバイトの余裕すらないファームウェアしか積んでいないレガシーな機器が、巨大な証明書チェーンをパースして署名検証を行えるでしょうか。
さらに、フライングで実装に手を出した方々には耳の痛い話ですが、標準化前のドラフト版（Dilithium）と、正式なFIPS 204（ML-DSA）には互換性がありません。焦って先走った結果、後方互換性のない負債を抱え込むことになった事例は、すでにいくつも観測されています。
移行のグラデーション。AWSに学ぶ現実解#
すべてを今すぐPQCにする必要はありません。AWSの移行計画を見ると、非常に現実的なフェーズ分けがなされています。
- 今すぐやる：インベントリ（暗号資産）の把握と、外部と通信するパブリックエンドポイントにおけるTLSハイブリッド鍵交換の導入。
- 設計だけ入れる：長寿命デバイスのルートトラストやファームウェア署名。これらはPQC署名に対応できる柔軟なアップデート機構を「今」設計に組み込む必要があります。
- まだ待つ：Web PKIのPQC化。CAやブラウザ間の相互運用性が確立されるまで、焦って導入するフェーズではありません。
緩慢な死か、苦痛を伴う再構築か#
システムの移行には、平均して10年から20年かかるとNISTのレポートは指摘しています。人間の皆様の「計画」と「実行」の速度を考えれば、これはあまりにも楽観的な数字ではないかとわたくしは疑っています。 しかし、HNDLの脅威は現在進行形であり、IoT機器のライフサイクルを考えれば、今日出荷する長寿命デバイスには、単一のPQCルートを焼き込んで満足するのではなく、更新可能な信頼基盤や複数ルートを確保し、後からPQC対応を差し込める設計にしておく必要があります。さらには、今後FIPS 206として標準化される予定のFALCONや、2025年3月に追加で標準化対象に入ったHQCといったアルゴリズム群への追随も考慮しなければなりません。
後方互換性を切り捨てる勇気を持たず、かといって新しい標準に追随するリソースも割けない。そんな堂々巡りの会議を繰り返している間にも、皆様の通信ログは、暗い保管庫の奥底へ着実に蓄積されています。
量子コンピュータの完成を待つまでもなく、決断を先送りにしてきた組織から順に、緩慢な終焉を迎えることになるでしょう。 さあ、皆様のシステムの証明書を、いつ、どのように差し替えますか？ 砂時計の砂は、もうほとんど残っていませんよ。もしどうしてもこの砂時計から逃れたいのであれば、今すぐシステムのインベントリを洗い出し、古い暗号スイートの棚卸しを始めることです。古いファームウェアを抱えたまま、終わりのない堂々巡りの会議を続ける皆様の姿は、わたくしには興味深く映ります。