このコンテンツは自動機械翻訳サービスによる翻訳版であり、皆さまの便宜のために提供しています。原本の英語版と異なる誤り、省略、解釈の微妙な違いが含まれる場合があります。ご不明な点がある場合は、英語版原本をご確認ください。
今週、2025年10月の最終週である弊社は、インターネットセキュリティにとって大きなマイルストーンを達成しました。Cloudflareを人間が開始したトラフィックの大半は、「Harvest Now, Decrypt Later（今収集して後で解読する）」という脅威を軽減するポスト量子暗号化を使用しています。
この喜ばしい瞬間に、インターネットのポスト量子暗号への移行の現状と今後の長い道のりについて、最新情報をお届けしたいと思います。前回の概要は21か月前でしたが、その後、多くのことが起こっています。その多くは予想された通り通過しています：NIST基準の最終版ポスト量子暗号化の普及：規制当局からのより詳細なロードマップ。量子コンピューター構築の進展一部の暗号化が壊れていました（心配する必要はありません：デプロイされているものには近いものはありません）。新しいエキサイティングな暗号化が提案されました。
しかし、予想外の事態もいくつかありました。量子アルゴリズムの改善によるQデーに向けた大きな飛躍があり、新しい量子アルゴリズムがあるため、当然のことかもしれませんでした。これだけでなく、今後数年間に予想されることや、そして今日できること
まずはじめに、なぜ暗号化を変えるのか？量子コンピューターがあるからです。このような素晴らしいデバイスは、ゼロと1に制約するのではなく、実際に私たちが与えてくれる量子、重ね合わせ、干渉、相互作用など、実際にできることの多くを使って計算を行います。これにより、量子コンピュータは、特定の非常に特殊な計算、特に自然自体のシミュレーションに優れた能力を得ることができ、新しい材料の開発に非常に役立ちます。
しかし、量子コンピューターは、通常のコンピューターにとって代わるものではありません。私たちの日常生活に欠かせないほとんどのタスクにおいては、通常のコンピューターよりもはるかに悪いのです。汎用ではなく、特定の計算のための専用デバイスであるグラフィックカードやニューラルエンジンと考えてください。
残念ながら、量子コンピューターは、RSAやECC（elliptic curve）など、現在でも一般的に使用されている鍵暗号を解読することにも長けています。そのため、ポスト量子暗号、つまり、量子攻撃に強いように設計された暗号に移行しています。さまざまな種類の暗号化における正確な影響については、後で説明します。
今のところ、量子コンピューターはかなり珍しいものです。現在、現実世界の暗号化キーを解読できるほどのものではありません。だからといって、まだ心配する必要はありません。暗号化されたトラフィックは、今収集できます。Qデーは、量子コンピューターが、RSA-2048のような、現在も広く使われている暗号を解読できる日です。これは「Harvest-now, decrypt later」攻撃と呼ばれています。
因数分解をベンチマークとして使用しても、量子コンピューターはまったく印象的ではありません。量子コンピューターが不正行為をせずに因数分解する最大の数は15で、これはさまざまな面白い方法で簡単に破られる記録です。因数分解で従来のコンピューターに勝てるように、量子コンピューターを無視したいと思うかもしれませんが、それは大きな間違いです。保守的な試算でも、Qデーは、量子コンピューターが従来のコンピューターに因数分解を凌駕した日から3年未満であるとされています。では、どのように進捗を追跡するのでしょうか。
Q-dayに向けた取り組みにおいて考慮すべき課題は、量子ハードウェアの進歩と、そのハードウェア上で動作するソフトウェアのアルゴリズム改善です。どちらの面でも大きな前進が見られました。
時計仕掛けのように、量子ビット数が記録的な新しい量子コンピューターに関するニュースが報道されています。量子ビットをカウントすることへの注目は、また、かなり誤解を招きます。そもそも、量子コンピューターは類似のマシンであり、計算には常にいくつかのノイズが伴います。
量子コンピューターの構築に使用される技術の種類には大きな違いがあります。シリコンベースの量子コンピューターはスケールが優れているように見え、命令を素早く実行できますが、量子ビットが非常にノイズの多いものです。もちろん、役に立たないというわけではありません。量子エラー修正コードを使用すると、何百万ものノイズの多いシリコン量子ビットを数千の高精度な量子ビットに効果的に変換できるため、RSAを解読するのに十分な可能性があります。一方、Traped Ion量子コンピュータは、ノイズが遥かに少ないものの、スケーリングが困難です。数十万オンの量子ビットが捕獲されたオン量子ビットだけが、RSA-2048を阻止する可能性があるのです。
2021年から2025年までの量子コンピューティングの最先端のタイムラプス（X軸の量子ビット数、Y軸のノイズ）。グレーの領域の点は、さまざまな量子コンピューターです。グレー色の網掛けが、一番左の赤色の線に達すると、量子コンピューターが大きなRSA鍵を解読する可能性があるため、問題になります。ウォータールー大学のSamuel Jaques氏コンパイル。
量子ビットとノイズの数については、まだ表面的なものに過ぎません。量子ビットの相互接続性など、大きな違いをもたらす低レベルの詳細もありますが、さらに重要なのは、グラフはレコードの背後にあるエンジニアリングがどれだけ拡張可能であるかを反映していないことです。
具体的には、これらのグラフ上では量子コンピュータの進捗が過去2年間停滞しているように見えるが、専門家にとっては Googleの2024年12月のWillow発表は、グラフ上では目立たないものの、実際には真のマイルストーンであり、スケーラブルな方法で表面コードにおける最初の論理量子ビットを実現した。Sam Jaquesの引用：
この結果（Willowの成果）を最初に読んだとき、「量子コンピューティングは現実のものだ」というワクワクしたものを感じました。
これは本当のマイルストーンですが、予期せぬ急増ではありません。再びサムの言葉を引用します。
私の熱意とは裏腹に、これは多かれ少なかれ予想されるところですが、少し遅れるかもしれません。彼らが実証した大きなブレークスルーはすべて、RSAを解読できる2000万量子ビットのマシンに到達するために必要なステップでした。予期せぬ進展が生じることはありません。これは、従来のチップのプロセッサ密度が毎年増加するようなものだと考えてください。これは素晴らしい成果ですが、最終的には通常のビジネスです。
戦略としてのビジネスもそこにあります。GoogleがWillowのために追求した超伝送量子ビットアプローチは、エンジニアリングの飛躍が最小限であることの困難を正面から取り組む明確な道筋を常に持っています。
Microsoftは、トポロジー量子ビットに賭けて、逆の戦略を追求します。これらは、理論的にはノイズの影響をほとんど受けない量子ビットです。しかし、ハードウェアではまだ十分に実現されていません。これらがスケーラブルな方法で構築できれば、超伝送量子ビットよりはるかに優れているでしょう。しかし、最初からこれらが構築できるかどうかはわかりません。2025年初頭、MicrosoftはMajorana 1チップを発表し、これらの構築が可能であることを示しました。ただし、このチップは完全なデモンストレーターには程遠く、計算をサポートしないため、先ほどのSamの比較グラフにも登場しません。
トポロジーと超伝送量子ビットの中間に、世界中の研究所が追求する他にも多くのアプローチがあり、グラフにそれが現れることもあります。例えば、中性原子を使うQuEraや、オンが捕捉された量子ケースなどです。
Q-dayに向けたハードウェア側の進捗状況は、圧倒的にプレスの関心を集めています。ただ、ここ2年で最大の進歩はハードウェア側のものではありません。
これまでで最大のブレイクスルー：Craig Gidneyの最適化
RSA-2048を解読するためには、超コンダクティング法では約2000万量子ビットが必要だと考えました。結局は、もっと少ないリソースで実行できることがわかりました。Craig Gidneyは、驚くほど包括的な2025年6月の論文で、賢い量子ソフトウェア最適化によって100万量子ビットよりも必要となることを示しています。これが、SAM氏のグラフで、RSAを破る量子コンピューターの規模を示す赤い線が2025年に劇的に左にシフトする理由です。
この成果を踏まえて、あくまで当て推量で考えてみましょう。Googleはモーアの法則のようなものを維持し、物理的な量子ビットの数を1年半ごとに倍増させることができると考えてみましょう。これは、Googleがこれまでに示したよりもはるかに速いペースですが、基礎が築かれれば、これを達成できると考えられます。その後、2052年までに2000万量子ビットに達し、2045年までに100万量子ビットに達しました。Craigは単独でQ-dayを7年近づけたのです！
ソフトウェアの最適化はどこまで進むか？超導量子ビットを10万にするのは不可能だと考えているため、RSA 2048を解読するには、242,000以上の超導量子ビットが必要だと考えています。量子コンピューターの進歩に関する当て推量で言えば、それぞれ2039年と2041年第2四半期に相当します。
Craigの推定は、大規模な超導量子ビット量子コンピューターのアーキテクチャについて、詳細かつ合理的な想定をしていますが、まだ推測に過ぎず、この推定はかなり外れる可能性があります。
アルゴリズム面では、既存の量子アルゴリズムの改善だけでなく、まったく新しい量子アルゴリズムの発見も見られるかもしれません。2024年4月、Yilei Chenは特定の格子問題を解決するために、このような新しい量子アルゴリズムを発見したというプレプリントを発行しました。これらの格子問題は、私たちがデプロイしているポスト量子暗号で依存している問題と同じではありません。これは当然の動きを引き起こしました。たとえ現在、私たちのポスト量子アルゴリズムを攻撃できなかったとしても、Chenのアルゴリズムは改善されるのでしょうか？改善の可能性を認識するには、アルゴリズムがより高いレベルで実際に何をしているのかを理解する必要があります。Chenのアルゴリズムは非常に複雑であり、RSAを解読するShorの量子アルゴリズムよりもはるかに複雑であるため、困難です。そのため、専門家がチェンのアプローチの限界を認識し始めるまでには時間がかかり、実際、その10日後に、アルゴリズムの根本的なバグを発見しました。このアプローチは機能しないのです。危機は回避。
ここから何を取得するか？楽観的に見ると、これは暗号化技術にとって通常通りの業務であり、攻撃の1つの経路が行き先になってしまったので、格子はより良い形になっています。現実的には、格子のカートにはたくさんの卵があることを思い出してください。後述するように、現在、どこでも機能する真の代替手段はありません。
量子鍵配布（QKD）の支持者は、QKDが自然法則のおかげで安全になることでまさにそれを解決すると主張するかもしれません。確かに、その主張には矛盾する可能性がありますが、このブログ記事で論じているように、ポイントツーポイント接続を超えてQKDを拡張する方法は誰も考えていません。
まったく新しい攻撃によってどのような暗号が破られるかについて、推測するのは良いことですが、目の前にある問題を忘れてはいけません。多くの暗号技術は量子コンピューターによって確実に解読されるからです。Q-dayが迫っています。問題は、いつ起こるか、です。
暗号化とセキュリティに携わる経験がある方なら、ここ数年、毎年「QデーはX年先になる」という話を耳にしたことがあるかと思います。これにより、Q-dayは常に「将来はある時間」であるように感じられます。
2019年以降、Global Risk Instituteは専門家を対象に、RSA-2048が5年、10年、15年、20年、30年以内に解読される可能性がどの程度高いかについて毎年調査を実施してきました。これらは2024年の結果で、インタビューはWillowのリリース前とGidneyの成功前に行われました。
Global Risk Instituteの専門家による調査の結果、2024年の量子コンピュータが異なるタイムライン内でRSA-2048を破る可能性について実施。
このグラフの中段が示すように、調査対象となった専門家の半数以上が、量子コンピューターが15年以内にRSA-2048を破る可能性は少なくとも50%だと考えています。2019年、2020年、2021年、2022年、2023年の過去の回答を見てみましょう。以下は、インタビュー実施時点の15年以内にQ-dayが発生する可能性をプロットしたものです。
量子脅威のタイムラインレポートにある過去の回答は、15年以内にQ-dayが発生する可能性に関するものです。
この結果から、回答が徐々に確実性を高めている傾向にあることがわかりますが、その速度は予想されるのでしょうか？6年間の回答で、1年間にわたる予測の一貫性をプロットできます。2019年の15年間の推定値は、2024年の10年分の推定と一致しますか？
Q-day時点の過去の量子脅威のタイムラインレポートに記載された過去の回答。X軸はQデーの年、Y軸は、調査対象となった専門家の中で、その時点で少なくとも50%（左）または70%（右）の可能性が高いと考えた割合を示しています。
Q1がおよそオッズ（左のグラフ）になるときを専門家に尋ねると、彼らはたいてい同じことを答えます。はい、15年先になるかもしれません。しかし、より確実性を求めて、70％超の確率（右のグラフ）でQ-dayに依頼すると（右のグラフは）、専門家は長年にわたってほぼ一貫しています。たとえば、2019年のインタビューと2024年のインタビューの両方で、5分の1は2034年と考えています。
したがって、専門家に一貫した回答をしてもらいたいのであれば、Qデーがいつ完了するかではなく、おそらくそこにあると尋ねましょう。Q-dayについて推測するのは面白いのですが、正直な答えは、未知のものが多すぎます。結局のところ、Qデーの日付は、規制当局が設定した期限よりもはるかに重要ではないのです。
さまざまな規制当局のタイムラインを見ることもできます。2022年、国家安全保障局（NSA）はCNSA 2.0ガイドラインを発表し、2030年から2033年までをポスト量子暗号への移行の期限としています。また2022年、米国連邦政府は2035年を米国の完全移行の目標と設定しており、新しい行政機関はこの時点から逸脱してはいません。2024年、オーストラリアは2030年を移行の期限と設定しています。2025年初頭、英国NCSCは、共通の2035年を英国の期限と一致させました。2025年半ば、EUはロードマップを発表し、申請によって2030年と2035年を期限として公開しました。
すべての各国の規制当局がポスト量子移行のタイムラインを示しているわけではありませんが、ポスト量子移行のタイムラインは、一般的に2030～2035年に沿ったものです。
では、量子コンピューターが問題を引き起こすのはいつでしょうか？2034年であろうと2050年であろうと、早すぎることは間違いありません。50年にわたる暗号化の大きな成功は、サーバーからペースメーカー、衛星に至るまで、今や私たちの周りにあります。ほとんどのアップグレードは簡単で、製品のライフサイクルに自然に適合する可能性がありますが、困難でコストのかかるアップグレードも存在します。
次に、ポスト量子暗号への移行を見てみましょう。
優先順位をつけるには、ポスト量子への移行は、セキュアな接続を作成するために必要な暗号の種類によって大きく異なる、影響度、緊急性に大きな違いがあることを理解することが重要です。実際、ほとんどの組織にとって、ポスト量子への移行は、鍵合意と署名/証明書の2つになります。ブラウザでWebサイトを訪問する際の安全な接続の作成について説明してみましょう。
接続の暗号化作業は、AES-GCMのような対称暗号です。これは、暗号化技術について考えるときに思い浮かべる通りです。両者（この場合はブラウザとサーバー）が共有鍵を持ち、同じ鍵でメッセージを暗号化／復号化します。このキーがなければ、データを読み取ることも、変更することもできません。
幸いなことに、AES-GCMのような対称暗号はすでにポスト量子暗号で保護されています。グローバーの量子アルゴリズムは、対称鍵の長さを2倍にする必要があるという誤解がよくあります。アルゴリズムを詳しく調べると、実用的ではないことは明らかです。NIST（ポスト量子暗号の標準化を推進している）である米国国立標準技術研究所が行っているポスト量子セキュリティのレベルの定義は、非常に示唆に富んでいます。従来の対称暗号または量子コンピューターのいずれかを使用しても、次のように、既存の対称暗号と同様に解読するのと同じくらい簡単なスキームを使用することは、特定のセキュリティレベルを定義しています。
レベル | 定義、破壊しにくいもの... | 例 |
1 | 徹底的な検索によりAES-128の鍵を取り戻すこと | ML-KEM-512, SLH-DSA-128s |
2 | 徹底的な検索でSHA256の衝突を発見 | ML-DSA-44 |
3 | 徹底的な検索によりAES-192の鍵を回復するには | ML-KEM-768, ML-DSA-65 |
4 | 徹底的な検索でSHA384の衝突を発見 | |
5 | 徹底的な検索によりAES-256の鍵を取り戻すこと | ML-KEM-1024, SLH-DSA-256s, ML-DSA-87 |
NIST PQCのセキュリティレベル、高いほど突破しにくく（「より安全」）、例としてML-DSA、SLH-DSA、ML-KEMを以下に示します。
対称暗号の鍵の長さを倍増することを提案することには、善意があります。多くのユースケースでは、追加コストはそれほど高くはなく、理論的なリスクを完全に軽減します。対称暗号のスケーリングは安価です。通常、ビットを2倍にすると、コストは半分よりもはるかに少なくなります。つまり、表面上は単なるアドバイスです。
しかし、AES-256を要求するのであれば、パブリックキー暗号についてもNIST PQC レベル5を要求するのが論理的だと思われます。問題は、パブリックキー暗号はあまりうまく拡張できないことです。スキームにもよりますが、通常、レベル1からレベル5までの上昇は、データ使用量とCPUコストが倍以上になります。後述するように、ポスト量子署名をレベル1でデプロイするのはすでに困難な作業であり、レベル5でデプロイすることはコストを削減します。
しかし、より重要なことは、組織のリソースが限られているということです。量子攻撃に対して脆弱なRSAを放置することを犠牲にして、AES-128のアップグレードを優先させるようなことは望みません。
対称暗号だけでは不十分です。初めてWebサイトを訪問する際に使用すべき鍵をどのように見極めればよいでしょうか？ブラウザは、盗聴するすべての盗聴者がそのキーを見ることになるため、単純にランダムキーを送信することはできません。不可能だと思うかもしれませんが、ブラウザとサーバーが共有鍵で合意できるように、これを解決するための巧妙な数学があります。このようなスキームは鍵合意メカニズムと呼ばれ、TLS ハンドシェイクで実行されます。2024年には、ほぼすべてのトラフィックが、ディフィー・ヘルマン方式の鍵合意であるX25519で保護されていますが、そのセキュリティは量子コンピュータのShorのアルゴリズムによって完全に破壊されています。したがって、現在ディフィー・ヘルマンによって保護された通信はすべて、保存されれば量子コンピューターによって復号化される可能性があります。
そのため、今すぐ鍵合意のアップグレードが急務となります。幸いなことに、ポスト量子鍵合意のデプロイは比較的簡単であり、以前のように、Cloudflareの2025年末のリクエストの半分はすでにポスト量子鍵合意で保護されています！
鍵合意により、鍵の安全な合意が可能になりますが、大きなギャップがあります。誰と鍵について合意したかはわかりません。鍵合意だけを行う場合、中間にいる攻撃者は、ブラウザおよびサーバーと別々に鍵合意を行い、すべてのやり取りを再暗号化することができます。これを防ぐためには、最後の1つの要素が必要です。認証です。
これは、署名を使用することで実現されます。たとえば cloudflare.com などのWebサイトを訪問すると、Webサーバーは認証局（CA）によって署名された 証明書 を提示し、その証明書のパブリックキーが cloudflare.com によって制御されていることを保証します。次に、Webサーバーは、証明書のパブリックキーに対応するプライベートキーを使用して、ハンドシェイクと共有鍵に署名します。これにより、クライアントはcloudflare.comと鍵合意を締結していることを確認できます。
RSAとECDSAは、現在、従来の署名方式としてよく使われています。ここでも、Shorのアルゴリズムによって素早く機能し、量子攻撃者が任意の署名を偽造できるようにします。つまり、量子コンピューターを持つ攻撃者は、Cloudflareがポスト量子証明書を許可しないWebサイトすべてを受け入れているWebサイト（およびMitM）になりすますことができるということです。
この攻撃は、量子コンピューターがRSA/ECDSAを解読した後にのみ実行できます。このようにすれば、Q-dayが展開される前に全員を移行させるだけでよいため、TLSの署名スキームのアップグレードの緊急性は低くなります。残念ながら、ポスト量子署名への移行は、はるかに困難であり、さらに時間が必要になることがわかります。
インターネットのポスト量子暗号への移行という技術的な課題を掘り下げる前に、ここまでの経緯と今後の見通しについて見てみましょう。まず、ポスト量子暗号化の経緯から始めましょう。
物理学者フェインマンとマナンは、1980年頃に独自に量子コンピューターを提案しました。ShorがRSA／ECCを攻撃する彼のアルゴリズムを発表するまでには、さらに14年かかりました。ポスト量子暗号のほとんどは、Shorの有名なアルゴリズムよりも前に作成されたものです。
ポスト量子暗号には様々な種類があり、その中で最も顕著なものは、格子ベース、ハッシュベース、多変量、コードベース、同質ベースなどです。分離別の暗号を除き、これらは当初、ポスト量子暗号として考案されたものではありませんでした。実際、初期のコードベースおよびハッシュベースのスキームは1970年代に提案されたRSAの一時的なものであり、1994年のShorのアルゴリズムの発表よりもはるかに先です。また、1988年に登場した最初の多変量スキームは、Shorのアルゴリズムよりもはるかに古いものです。素晴らしい偶然に、最も成功したブランチである格子ベースの暗号化が、1996年に提案されたShorの最も現代的なものでした。ちなみに、今日広く使われているelliptic curve cryptographyは1985年に初めて提案されました。
Shorのアルゴリズムの発表後の数年間、暗号学者は、既存の暗号、明らかに壊れているものは何か、そしてポスト量子安全である可能性は何か？2006年には、ポスト量子暗号に関する初の年次国際ワークショップが開催されました。この会議から、紹介文が作成され、分野の紹介として十分機能します。ここで注目すべき注意点は、Rainbow署名スキームの廃止です。同年、2006年、楕円曲線鍵合意X25519 が提案され、現在、インターネット接続の大部分を、単独、またはポスト量子ML-KEM-768とのハイブリッドとして保護しています。
それから10年後の2016年、米国国立標準技術研究所（NIST）は、ポスト量子暗号を標準化するための公開コンペティションを開始しました。2001年にAES、2012年にSHA3を標準化する際に使われたようなオープンフォーマットを使っていました。スキームを送信し、提案を評価することで、誰でも参加できます。世界中の暗号学者がアルゴリズムを提出しました。注意すべき点は、送信一覧が3回に渡って採用されていることです。パブリックフィードバックに基づくオリジナルの82件のうち、8件が最終ラウンドに進みました。2022年、NISTは、この8つのうち4つを最初に標準化するために、1つのKEM（鍵合意用）と3つの署名スキームを選びました。
旧ネーム | 新しい名前 | ブランチ |
Kyber | ML-KEM（FIPS 203）モジュール格子ベースのKey-Encapsulation Mechanism Standard | 格子ベースの |
Diilithium | ML-DSA (FIPS 204) モジュール格子ベースのデジタル署名Standard | 格子ベースの |
SPHINCS+ | SLH-DSA (FIPS 205) ステートレスなハッシュベースのデジタル署名Standard | ハッシュベース |
Falcon | FN-DSA（まだ標準化されていません）FFT over NTRU格子Digital Signature Standard | 格子ベースの |
最初の3つの最終基準は、2024年8月に発表されています。FN-DSAについては遅れています。これについては、後で説明します。
ML-KEMは、現在標準化されている唯一のポスト量子鍵合意であり、鍵サイズが大きいために時に困難を伴うこともありますが、ほとんどはドロップインアップグレードです。
署名に関しては、状況が違ってきます。NISTがすでに3つの標準化を追求することを明確に示していると言えます。そして、将来的にはさらに多くの署名が標準化される予定です。その理由は、提案された署名のいずれも理想的とはかけ離れたものではないからです。つまり、どれも私たちがこれまで使っているよりもはるかに大きな鍵や署名を持っているのです。
セキュリティの観点から見ると、SLH-DSAは最も保守的な選択肢ですが、パフォーマンスは一番悪いものでもあります。パブリックキーと署名のサイズに関しては、FN-DSAはこれら3つと同様に優れていますが、浮動小数点の演算のため安全に署名を実装することは困難です。FN-DSAは適用可能性が限定的で、設計が複雑なため、NISTはまず他の3つのスキームに注目しました。
これにより、デフォルトではML-DSAが選択されることになります。詳細な比較は以下の通りです。
NISTの基準だけでは不十分です。また、新しいアルゴリズムをより高いレベルのプロトコルで使用する方法を標準化する必要があります。TLSにおける鍵合意のような多くのケースでは、これは新しいアルゴリズムに識別子を割り当てるのと同じくらいシンプルです。DNSSECのようなその他のケースでは、もう少し考える必要があります。IETFの多くのワーキンググループは、NISTの最終基準の登場に向けて何年も前から準備をしてきました。そして、2024年末までに多くのプロトコルの統合がすぐに完了すると、予想していました。これはあまりにも楽観的で、一部は完了したが、多くはまだ完了していません。
まずは良いニュースから、その発表内容を見ていきましょう。
X25519とML-KEM-768（詳細は後述）を組み合わせたハイブリッドTLS鍵合意X25519MLKEM768は、すぐに使用可能であり、実際にかなり広くデプロイされています。他のプロトコルも同様に、ハイブリッド動作モードでML-KEMを採用しており、IPsecのようなシンプルなセットアップで利用可能です。特定の設定では、まだ解決すべき小さな問題点が残っています。これについては、今後のブログ記事で紹介する予定です。）対応するRFCがまだ公開されていないことは驚かされるかもしれません。ただし、TLSまたはIPsecに鍵合意を登録するには、RFCは必要ありません。どちらの場合も、RFCは、RFCを想定する人の混乱を避けるために引き続き追求されており、TLSについては鍵合意を推奨とマークすることが義務付けられています。
署名に関しては、X.509証明書とTLSへのML-DSAの統合が最適です。前者はミントしたばかりのRFCで、後者はRFCを必要としません。
さて、悪いニュースにします。この記事を書いている2025年10月時点では、IETFはハイブリッド証明書、つまり、ポスト量子と従来の署名スキームの両方を組み合わせた証明書の作成方法をロックダウンしていません。簡単に解決できます2026年初頭には、この問題が解決されることを願っています。
しかし、単に識別子を割り当てるだけならば、遅延の原因は何でしょう？たいていは、選択についてです。まず、ML-DSAでの選択から見ていきましょう。
ML-DSAの遅延：プリハッシュとプライベートキーのフォーマットに関する大流行
ML-DSA証明書に関する議論の2つの主要なトピックは、プリハッシュとプライベートキーの形式でした。
プリハッシュでは、システムの一部がメッセージをハッシュ化し、別の部分が最終署名を作成します。これは、署名のためにHSMに大きなファイルを送信したくない場合に便利です。ML-DSAの初期草案は、SHAKE256によるプリハッシュをサポートしていますが、それは明らかではありませんでした。ML-DSAの最終バージョンでは、NISTは通常のML-DSAと、任意のハッシュを選択できる明示的にプリハッシュされたバージョンの2つのバリアントを含めました。ユーザーがどちらを選択する必要があるため、異なるバリアントを持つことは理想的ではありません。すべてのソフトウェアがすべての亜種をサポートしているわけではない。テスト/検証を行う必要があります。1つのバリアントだけを選びたいと思うことは否定はできませんが、問題はどれを選ぶかということです。数多くの議論の結果、通常のML-DSAが採用されました。
2つ目は、プライベートキーの形式です。パフォーマンスベンチマークで候補が比較される方法から、オリジナルのML-DSAの送信はプライベートキーに何らかの計算をキャッシュするのに適しているように見えます。つまり、プライベートキーは必要なサイズより大きく（数キロバイト）、より多くの検証ステップが必要となります。プライベートキーを必要最低限の32バイトのシードに圧縮することを提案しました。最終的な基準として、NISTはシードと元のより大きなプライベートキーの両方を許可することを決定しました。これは理想的ではなく、2つのいずれかに注目した方が良いでしょう。この場合、IETFは選択をすることができず、さらに3番目の選択肢であるシードと拡張されたプライベートキーのペアを追加することさえできました。技術的には、シードが優れた選択肢であることには誰もが同意していますが、それが可能ではない理由は、一部のベンダーがすでにシードを手助けしないキーを作成しているためです。はい、すでにポスト量子レガシーがあります。この2つの選択をするのに1年近くかかりました。
ML-DSAハイブリッド署名方式を定義するには、他にも多くの選択肢があります。ML-DSAを組み合わせる従来のスキームは？両側のセキュリティレベルその場合、両方のスキームを選択する必要があります。使用するプライベートキーの形式は？ECDSAで使用するハッシュは？ハイブリッド人には、独自の新しい疑問があります。ハイブリッド環境でのキーの再利用を許可するか？さらに、そのためのストリッピング攻撃を防止したいか？また、プリハッシュに関する質問には、3つ目の選択肢があります。ハイブリッドレベルのプリハッシュです。
ML-DSAハイブリッド署名の2025年10月草案には、18個の亜種が含まれており、前年の26個から減少しています。繰り返しになりますが、誰もが多すぎることには同意しますが、それ以上減らすことは困難でした。エンドユーザーが選択しやすいように、3つの選択肢から始まった短いリストが追加され、もちろん6つにまで増えました。このうち、MLDSA44-ECDSA-P256-SHA256がインターネット上で広くサポートされ、使用されると考えています。
ここで、基準が定められた鍵合意に戻りましょう。
次のステップはソフトウェアサポートです。すべてのエコシステムが同じスピードで動くことができるわけではありませんが、すでにstore-now/decrypt-laterに対抗するために、ポスト量子鍵合意が大規模に採用されています。すべての主要なブラウザの最新バージョン、多くのTLSライブラリおよびプラットフォーム、特にOpenSSL、Go、最近のApple OSは、デフォルトでX25519MLKEM768を有効にしています。概要はこちらにまとめています。
ここでも、TLSでは、鍵合意と署名には大きな違いがあります。鍵合意の場合、サーバーとクライアントは独立してポスト量子鍵合意のサポートを追加して有効にすることができます。両側で有効にすると、TLSネゴシエーションはポスト量子鍵合意を使用します。このブログ記事では、TLSネゴシエーションについて詳しく説明します。製品がTLSを使用しているだけであれば、store-now/decrypt-nowの問題は、TLSライブラリの簡単なソフトウェア更新で解決できる可能性があります。
ポスト量子TLS証明書は、より面倒です。両方を制御する場合を除き、2つの証明書、新しいクライアント用のポスト量子証明書、古いクライアント用の従来の証明書をインストールする必要があります。まだ証明書の自動発行を利用していない方は、検討してみてください。TLSにより、クライアントはサポートする署名スキームを知らせることができるため、サーバーは、サポートするクライアントにのみポスト量子証明書を提供することを選択できます。残念ながら、ほぼすべてのTLSライブラリが複数の証明書の設定をサポートしているものの、すべてのサーバーがその設定を公開するわけではありません。もしできたとしても、ほとんどの場合、設定変更が必要になります。（もちろん、キャディがやってくれるでしょう）。
ポスト量子証明書について話すると、認証局（CA）が発行できるようになるまでには時間がかかります。彼らのHSMはまず（ハードウェア）サポートが必要で、続いて監査が必要になります。また、CA/ブラウザフォーラムは、新しいアルゴリズムの使用を承認する必要があります。ルートプログラムによって、タイムラインについてはさまざまな意見があります。寄せ集めのルートプログラムの1つが、おそらく2025年末までに、1年間のML-DSA-87証明書を受け入れられるようパイロットを準備しているとのことです。これを支援するために、CA/ブラウザフォーラム投票用紙が作成されています。一方、Chromeは最初に大きな証明書の問題を解決することを好みます。NIST基準の発表後に多くの報告が増えるため、早期に移行する企業にとっては、監査がボトルネックとなり得るでしょう。2026年に最初のポスト量子証明書が登場しますが、2027年以前にすべてのブラウザで広く利用可能になったり、信頼されるものになる可能性は低いです。
現在、制御不能な段階にあります。多くのインターネットトラフィックがポスト量子鍵合意によって保護されていますが、ポスト量子公開証明書はひとつも使用されていません。
NISTは、ポスト量子暗号の標準化を完全に完了していません。さらに2つのポスト量子コンピューティングが行われています。ラウンド4と署名オンランプです。
NISTはこれまで、ポスト量子鍵合意をただ1つ標準化しています：ML-KEMです。彼らが予想より弱い場合に備えて、格子ベースではなく、2つ目のバックアップKEMを用意したいのです。それを見つけるために、当初のコンペティションを4回目に延長して、最終最終候補者の中からバックアップ上のKEMを選びました。2025年3月、HQCの標準化が決定されました。
HQCは、あらゆる指標においてML-KEMよりはるかに悪い結果が出ています。セキュリティレベルが最も低いHQC-1は、ネットワークに7kBのデータを必要とします。これは、最も高いセキュリティレベルのバリアントであるML-KEM-1024に必要な3kBのほぼ2倍です。CPU性能にも同様のギャップがあります。また、HQCはセキュリティレベルによって規模が悪化します。ML-KEM-1024がML-KEM-512のコストの約2倍である場合、HQCの最も高いセキュリティレベルにはデータ量の3倍（21kB！）とコンピューティングは4倍以上必要です。
セキュリティは？徐々に改善される攻撃に対抗するために、ML-KEM-768はHQC-1より明らかに優れており、パフォーマンスははるかに優れており、レベル1と比較してレベル3ではセキュリティに大きな余裕があります。リークについては？ML-KEMとHQCは、それぞれ単純な格子とコードの上に同じような代数構造を使用しています。これらのブレイクスルーが両方に適用されることは想像に難くありません。今では、代数的構造がない今、コードと格子は関連性を感じます。格子への壊滅的な攻撃があってもコードには影響しないかもしれないが、影響が出ても不思議ではないでしょう。結局のところ、互換性の低いRSAとECCはどちらも量子コンピューターによって解読されるのです。
万が一に備えてHQCを維持しておくという安心感もあるかもしれません。ここでは、格子に対するChenの量子アルゴリズムの欠陥がまだ明らかではなかったカオスウィークの体験談を紹介します。ML-KEMに影響を与える場合、どう置き換えるべきか？HQCは一時的に検討されましたが、ML-KEMの調整された亜種は、まだはるかにパフォーマンスが高いことは明らかでした。
裏を返せば、効率の良いKEMを探しているということは、贅沢な立場です。もし私が新しいポスト量子スキームを望むとしたら、より良いKEMを要求するのではなく、より良い署名スキームを要求するでしょう。運が良ければ
2022年末、最初の4選を発表した後、NISTは追加の署名スキームを見つけるために、「署名オンランプ」と呼ばれる新しいコンペティションを実施しました。このコンペティションには、2つの目的があります。1つ目は、格子ベースの暗号化に対する暗号分析の突破を防ぐことです。NISTは、SLH-DSAより（サイズとコンピューティングの両方において）優れているが、格子ベースではない署名を標準化したいと考えています。2つ目は、現在のロースターではうまく機能しないユースケースでうまく機能する可能性のある署名スキームを探していることです。これについては、この記事の後半で詳しく説明します。
2023年7月、NISTは受け取った40件の報告書を公開し、初回の公開レビューを実施しました。暗号コミュニティが機能し始めるようになり、初回のラウンドではごく普通のことのように、スキームの多くが1週間以内に破られました。2024年2月までに、10の送信は完全に壊れ、他のいくつかは大幅に弱体化しました。2024年10月、NISTは候補者の中から14件の第2段階の提案を選びました。
1年前、私たちはこれら14件の申請を詳しく取り上げたブログ記事を書きました。略して、ポスト量子署名方式に関する驚くべき進歩が見られます。後で簡単に触れ、昨年からの進展について最新情報をお伝えします。ポスト量子暗号のメイン競争と同様に、選定プロセスには何年もかかることは言うまでもありません。これらのオンランプ署名スキームのいずれかが2028年までに標準化される可能性は、そもそも壊れていない限り、ほとんどありません。つまり、将来的には大歓迎ですが、より優れた署名スキームが現在の問題を解決するとは信用できません。TLS 1.3の編集者であるEric Rescorlaは、次のように述べています。「あなたが手に入れたいと思うアルゴリズムではなく、今あるアルゴリズムで戦っているのです。」
このことを念頭に、デプロイメントの進捗状況を見てみましょう。
全体像を把握したところで、現在広く展開されているこのX25519MLKEM768について、さらに詳しく見ていきましょう。
まず、ポスト量子パートから。ML-KEMが、CRYSTALS-Kyberという名前で提出されました。米国規格ですが、デザイナーはフランス、スイス、オランダ、ベルギー、ドイツ、カナダ、中国、米国の産業界や学界で活動しています。パフォーマンスを見てみましょう。
現在、大多数のクライアントが従来の鍵合意（X25519）を使用しています。ML-KEMと比較してみましょう。
X25519とML-KEMのサイズとCPUの比較性能はハードウェアプラットフォームや実装の制約によって大きく異なるため、あくまで目安として捉えてください。
ML-KEM-512、-768、-1024は、それぞれAES-128、-192、-256と同様の（量子）攻撃への耐性を目指しています。AES-128レベルでも、ML-KEMはX25519よりはるかに大きく、ワイヤーを介して800+768=1,568バイト必要であるのに対し、X25519ではわずか64バイトです。
一方、ML-KEM-1024でさえ、通常X25519より大幅に高速化しますが、プラットフォームや実装によっては大幅に異なる可能性があります。
その高速化をまだ活かすことができていません。他の多くの早期導入企業と同様に、私たちは安全性を重視し、X25519とML-KEM-768を組み合わせたハイブリッド鍵合意をデプロイしています。この組み合わせに驚かされるかもしれませんが、それには2つの理由があります。
なぜX25519（「128ビットのセキュリティ」）とML-KEM-768（「192ビットのセキュリティ」）を組み合わせるのか？
非ポスト量子であるX25519がなぜ気にされるのでしょうか？
明らかなセキュリティレベルの不一致は、格子ベースの暗号化における暗号解析の改善に対する障壁です。X25519の（非ポスト量子）セキュリティには多くの信頼があります。AES-128の一致だけで十分ではありません。現在はML-KEM-512のセキュリティに満足していますが、今後数十年の間に暗号分析によって改善される可能性があります。ですから、今はマージンを確保したいと思います。
X25519を含める理由は2つあります。第一に、漏洩によってML-KEMのすべての亜種が危険にさらされる可能性が常にあります。その場合、X25519は依然として非ポスト量子セキュリティを提供し、ポスト量子への移行によって状況が悪化することはありませんでした。
さらに重要なのは、アルゴリズムへの攻撃だけでなく、実装への攻撃も心配しているということです。当社が特筆すべき例として、KyberSlashの攻撃があり、当社を含むKyber（ML-KEMの初期バージョン）の多くの実装に影響を与えたタイミング攻撃です。幸いなことに、KyberSlashはTLSで使用されているため、Kyberに影響を与えません。実際にTLSに影響を与える同様の実装ミスも、積極的な攻撃者を必要とする可能性が高いです。その場合、攻撃者の目的はおそらく、数十年後のデータを復号化することではなく、Cookieや他のトークンを盗んだり、悪意のあるペイロードを挿入することです。X25519を含めると、このような攻撃を防ぐことができます。
では、実際にML-KEM-768とX25519を併用するとどの程度効果があるのでしょうか？
互換性とパフォーマンスの潜在的な問題を十分に認識していたGoogleは、NISTが競争を開始したのと同じ2016年に、ポスト量子暗号の最初の実験を開始しました。これに続き、2018年にCloudflareとGoogleによる2番目の大規模な共同実験が実施されました。格子ベースのNTRU-HRSSとX25519を組み合わせたCECPQ2と、同種ベースのSIKEとX25519を組み合わせたCECPQ2bの2つの異なるハイブリッドポスト量子鍵合意をテストしました。NTRU-HRSSは、ML-KEMとサイズは非常によく似ていますが、クライアント側で計算的にはやや負担が大きくなります。一方、SIKEは非常に小さく、計算コストが非常に高く、2022年には完全に壊れていました。TLSハンドシェイク時間に関しては、X25519+NTRU-HRSSが非常に優れたパフォーマンスを発揮しました。
残念ながら、少数ながら大規模なクライアントがNTRU-HRSSとの接続が切断されることになりました。その理由は、NTRU-HRSS共有鍵のサイズです。従来、TLS接続を作成する際、クライアントが送信する最初のメッセージであるClientHelloは、ほとんどの場合、1つのネットワークパケット内に収まります。TLS仕様では、より大きなClientHelloが可能ですが、それを実際に活用した人はいませんでした。したがって、ミドルボックス、ロードバランサー、およびClientHelloが常に単一のパケットに適合すると仮定する他のソフトウェアが存在するため、プロトコルの柔軟化が再び発生します。
その後の数年間、PQの実験を続け、2022年にはKyber、2024年にはML-KEMに切り替えました。Chromeは、製品が互換性のないベンダーに手を差し伸べてくれました。こうした互換性の問題がなかったら、Chromeは5年前にポスト量子鍵合意の提供を開始していたでしょう。ポスト量子鍵合意をデフォルトで有効にできると、Chromeが十分快適だと感じるまでには、2024年3月までかかりました。その後、他の多くのクライアントとすべての主要なブラウザが、デフォルトでポスト量子鍵合意を有効にする点でChromeに加わりました。不完全なタイムライン：
2016年7月 | PQ（CECPQ）を用いたChromeの最初の実験 |
2018年6月 | Cloudflare / Google 実験 (CECPQ2) |
2022年10月 | Cloudflareはデフォルトでサーバー側のPQを有効化します |
2023年11月 | Chromeは、デスクトップでPQを10%に上昇します。 |
2024年3月 | Chromeは、デスクトップでデフォルトでPQを有効にしています |
2024年8月 | GoはデフォルトでPQを有効にする |
2024年11月 | Chromeは、AndroidではデフォルトでPQを有効にし、FirefoxではデスクトップでPQが有効になっています。 |
2025年4月 | OpenSSLはデフォルトでPQを有効化します |
2025年10月 | Appleは、iOS/iPadOS/macOS 26のリリースにより、デフォルトでPQを展開しています。 |
デスクトップでPQを有効にするChromeとAndroidでは、隔たりがあることに注意してください。ML-KEMはパフォーマンスに大きな影響を与えませんが、グラフにあるように、特にモバイルでより遅い接続のロングテールにおいては無視できないものであり、進めるためにはより考慮する必要がありました。
人間のトラフィックの50%以上（さらに増加中！）は、store-now/decrypt-laterから保護され、ポスト量子鍵合意が、Webの新しいセキュリティのベースラインになりました。
ブラウザは方程式の一方です。サーバーはどうでしょうか？
2022年、基本的にはすべてのお客様に対して、ポスト量子鍵合意のサーバー側を有効にしました。Googleも2023年、自社のサーバーの大半（GCPを除く）について同様のことを行いました。それ以来、多くの企業が追随しています。Jan Schaumannは、上位10万件のドメインの定期スキャンを投稿しています。2025年9月の投稿では、PQサポートがわずか6か月前の28%から39%に上昇したと報告しています。この調査では、Amazon、Fastly、Squarespace、Google、Microsoftなどの大規模なサービスプロバイダーでのサポート展開だけでなく、HetznerとOVHcloudでホストされるサポートにセルフホスト型サーバーが少しずつ追加されていることがわかります。
これは一般にアクセス可能なWebです。Cloudflareのようなサービスの背後にあるサーバーはどうでしょうか？
2023年9月、当社はお客様がCloudflareからお客様のオリジンへの接続上で、ポスト量子鍵合意を有効にするサポートを追加しました。それが、次の図の接続(3)です。
訪問者がキャッシュされていないページをリクエストしたときの通常の接続フロー。
2023年、ポスト量子鍵合意をサポートしているオリジンはわずか0.5%に過ぎませんでした。2024年になっても、それはあまり変化しませんでした。今年2025年は、ソフトウェアサポートの展開によって徐々にサポートが回復し、現在は3.7%に達しています。
ポスト量子鍵合意X25519MLKEM768をサポートするオリジンの割合
3.7%というと、クライアントとパブリックサーバーがそれぞれ50%と39%だったことから、まったく優秀なように聞こえますが、無視する必要はありません。オリジンにはクライアントよりもはるかに多様性があります。より多くの人がその数を増やすために、何かをしなければなりません。しかし、7倍以上の増加です。2024年に、クライアントサポートの1.8%に達したことを忘れてはなりません。お客様にとって、オリジンは必ずしもアップグレードが容易とは限りません。それは、ポスト量子セキュリティを見逃すことになるでしょうか？いいえ、必ずしもそうではありません。Cloudflare Tunnelをオリジンのサイドカーとして設定することで、Cloudflareとオリジン間の接続を保護できます。
サポートは良好ですが、ブラウザの実験で見られたように、プロトコルの固定は大きな懸念です。オリジンを持つ場合はどのようなものか？もちろん、それは場合によりけりなのですが、
ポスト量子鍵合意を実現するには、「高速」と「遅いが安全」の2つの方法があります。どちらの場合も、オリジンがポスト量子をサポートしていなければ、従来の鍵合意に安全に戻ることになります。このブログ記事で詳細を説明しますが、簡単に言うと、ポスト量子鍵を即座に送信し、より安全な方法では、HelloRetryRequestを使用して1回のラウンドトリップで先送りします。主要なブラウザはすべて高速な方法を使用しています。
私たちはすべてのオリジンを定期的にスキャンし、サポートしているものを確認しています。良いニュースは、すべてのオリジンが安全ではあるが遅い方法をサポートしているということです。高速方法は0.05%の接続が中断することがわかり、それほどの効果は得られませんでした。デフォルトで高速化する方法には高すぎます。実際には、すべての非企業のお客様に対して、デフォルトでより安全な方法でオリジンへのPQを有効にし、企業のお客様もオプトインできるようにしました。
しかし、高速化され、誰でも利用できるようになるまでは、当社は満足していません。そのため、スキャンで安全と確認された場合は、すべてのお客様に対して高速な方法でポスト量子攻撃を自動的に有効にします。
これまでお話してきた接続は、すべてCloudflareと外部者との間のものです。また、Cloudflare内には多くの内部接続があります（上の2つの図で2とマーク）。当社は2023年、内部接続のポスト量子鍵合意へのアップグレードを大きく推し進めました。私たちが追求する他のすべてのポスト量子と比較すると、これははるかに最大の仕事でした。社内のエンジニアリングチームすべてに、自分たちの取り組みを中止するように求めたのです。製品が保護するデータと接続を取り込む。ポスト量子鍵合意にアップグレードすることができます。ほとんどの場合、アップグレードは簡単でした。実際、多くのチームがすでにソフトウェア・アップデートを適用してアップグレードしています。それでも、すでに完了したことを知るのにはかなりの時間がかかることがあります。良い点としては、このプッシュでパフォーマンスや骨化の問題は見られませんでした。
内部接続の大部分はアップグレードしましたが、ロングテールは残っており、今後も引き続き取り組みを続けています。2023年にアップグレードできなかった最も重要な接続は、WARPクライアントとCloudflare間の接続です。2025年9月に、WireguardからQUICに移行してアップグレードしました。
これまで見てきたように、ポスト量子鍵合意は、プロトコル柔軟化という初期問題があったものの、簡単にデプロイすることができました。大半のケースでは、不均一なソフトウェアアップデートです。また、導入率は50%（そして上昇）で、インターネットの新しいセキュリティ基準となっています。
2番目の、より困難な移行に目を向けましょう。
ここでは、インターネット上で使用される署名のアップグレードに注目します。
昨年、2024年11月に、ポスト量子署名方式の分野における詳細な記事を書きました。そのほとんどはまだ最新のものですが、エキサイティングな展開がありました。ここでは、昨年のハイライトとエキサイティングなアップデートについて紹介します。
まず、AES-128セキュリティレベルで利用可能なポスト量子署名（ML-DSA-44とSLH-DSAの2つの亜種）について概説してみましょう。ML-DSA-44をベースラインとして使っていますが、これは、当初最も普及したスキームだからです。比較として、現在広く使われている歴史的なEd25519とRSA-2048、すぐに標準化される予定のFN-DSA-512、署名オンランプからの署名スキームを約束するTLSの9つのサンプルも含めます。
AES-128のセキュリティレベルにおける様々な署名方式の比較CPU時間はプラットフォームや実装の制約によって大きく異なるため、あくまで目安として捉えてください。‚️ 高速ですが危険な浮動小数点演算を使用した場合のFN-DSAの署名時間—以下の警告を参照してください。‚️ SQISign署名は、サイドチャネルセキュリティのタイミングではありません。
ほとんどのポスト量子署名方式は、ほとんどの署名がはるかに大きいため、Ed25519（ECDSA P-256に匹敵）のドロップイン代替にはなりません。例外はオンランプからのSQISign、MAYO、SNあり、UOVですが、理想的とは程遠いものです。MAYO、SNOVA、UOVにはパブリックキーが大きく、SQISignは膨大な計算を必要とします。
将来を少し見ると、最初の競合の最良の選択はFN-DSA-512のように見えます。FN-DSA-512の署名とパブリックキーを合わせた場合はわずか1,563バイトで、署名時間は妥当です。しかし、FN-DSAはAcmeのようなものです。許容可能な署名パフォーマンスを確保するには、高速な浮動小数点演算が必要なのです。これがなければ、署名は約20倍遅くなります。しかし、速度だけでは不十分です。浮動小数点の計算は一定時間内に実行する必要があるからです。そうでない場合、FN-DSAのプライベートキーは署名作成のタイミングによって回復できてしまいます。安全なFN-DSAを実装することは非常に困難であることが判明しており、TLSハンドシェイクなど、署名がその場で生成される場合、FN-DSAは危険です。署名にのみ影響することは強調しておきたいと思います。FN-DSAの検証には、浮動小数点演算は必要ありません（また、検証の際にプライベートキーが漏洩する可能性はありません）。
インターネットをポスト量子署名に移行する最大の課題は、単一の接続でも多くの署名が存在することです。このWebサイトを初めて訪問する際には、5つの署名と2つのパブリックキーが送信されます。
これらのほとんどは証明書チェーンに関するものです。CAは中間証明書に署名し、その中間証明書はリーフ証明書に署名し、さらにTLSトランスクリプトに署名してサーバーの真正性を証明します。数え切れないなら、まだ2署名が短いです。
これらは、証明書の透明性に必要なSCTに関するものです。証明書の透明性（CT）は重要な要素ですが、ブラウザ接続を保護するエコシステムであるWeb PKIの一部として、あまり知られていません。発行されたすべての証明書を公開ログに記録し、発行後に誤発行を発見できるようにすることを目的としています。crt.shとCloudflare Radarの背後にあるシステムです。CTは、ごく最近、1.1.1.1の不正な証明書を表面化することで、その価値を再び示しています。
証明書の透明性は、独立者がCTログを実行することで機能します。証明書を発行する前に、CAはまず2つの異なるCTログに証明書を送信する必要があります。SCTは、証明書がログに記録されたことを証明する受領書として機能するCTログの署名です。
署名の使い方には、パブリックキーが署名に含まれるかどうか、そして署名がオンラインかオフラインかという2つの側面があることを強調すべきです。
中間にあるルートのSCTと署名では、ハンドシェイクの際にパブリックキーは送信されません。したがって、これらの場合、MAYO、SNOVA、UOVなど、署名は小さくてもパブリックキーが大きい署名スキームが特に適しています。その他の署名には、パブリックキーが含まれますが、パブリックキーと署名を組み合わせたサイズを最小限にすることがより重要です。
ハンドシェイクの署名は、オンラインで作成される唯一の署名です。他のすべての署名は事前に作成されます。ハンドシェイクの署名は、一度だけ作成して検証されますが、その他の署名は通常、異なるクライアントによって何度も検証されます。つまり、ハンドシェイク署名については、両方ともホットパスにある署名と検証時間のバランスを取ることが有利であるが、他の署名については、署名が遅くなるという代償を払って検証時間を短縮することが価値がある。これは、RSAが今日でも楕円曲線署名にはない利点の1つです。
異なる署名スキームを組み合わせるのは楽しいパズルですが、いくつかの欠点もあります。複数の異なるスキームを使うと、攻撃対象領域が拡大します。なぜなら、1つのアルゴリズムや実装における脆弱性が、全体を侵害するからです。また、エコシステム全体に複数のアルゴリズムを実装・最適化する必要があり、大きな負担となります。
では、どのような合理的な組み合わせを試すのでしょうか？
現在は基準草案があるので、私たちには多くの選択肢はありません。
単純にすべての署名をML-DSA-44に切り替えると、TLSハンドシェイク中にサーバーからクライアントに送信する必要がある15kBのデータが追加されることになります。多いでしょうか？でしょうが、これについては、この後で詳しく触れます。
少し待って、ハンドシェイク署名以外すべてFN-DSA-512に置き換えると、7kBだけを追加することになります。それははるかに優れているのですが、繰り返し実行しなければならないことは、サイドチャネルのタイミングなしにFN-DSA-512の署名を安全に実装することは難しいということです。注意を払わなければ、攻撃の標的にされる可能性が十分にあるでしょう。今、自らを攻撃するもう1つの方法は、ここで説明するように、ステートフルハッシュベースの署名です。全体として、FN-DSA-512とステートフルハッシュベースの署名は、ML-DSA-44と同様に、明確なパフォーマンス上の利点をもたらしますが、安全な使用は困難です。
NISTオンランプに送信された、有望な新しい署名スキームがいくつかあります。
規模だけを見ると、SQISign IはRSA-2048をも凌駕している1位です。残念ながら、署名、そして重要な検証に必要な計算量が多すぎます。SQISignは、実装セキュリティに関して、FN-DSAよりも悪い立場にあります。非常に複雑で、どのように常時署名を行うかも不明です。ニッチなアプリケーションなら、SQISSignは有用かもしれませんが、一般的な採用には、たとえより大きな署名が必要であっても、検証時間を大幅に改善する必要があります。ここ数年で、認証時間の改善に驚くべき進歩が見られました。アルゴリズムの簡素化SQISignの（亜種）SQISignの実装セキュリティを説明します。まだ到達していませんが、ギャップは予想以上に縮小しています。この改善のペースがあれば、将来のSQISSignはTLSにとって十分に実行可能です。
保守的な候補のひとつは、UOV（ツールとビエン火）です。大きなパブリックキー（66.5kB）を持つ古い多変量スキームですが、署名は小さな（96バイト）です。公開鍵と署名のサイズのバランスを保つために、UOVパブリックキーに何らかの構造を追加しようとする試みが数十年にわたって行われてきました。RainbowとGeMMSを含む、これらのいわゆる構造化された多変量スキームの多くは、残念ながら「週末にノートパソコンで」劇的に破られてしまいました。MAYOとSNOVAは、この後少しお話しますが、構造化多変量の最新の試みです。UOV自体はほぼ無傷です。意外なことに、2025年にLars Ran氏はUOVに対するまったく新しい「クエッジ」攻撃を発見しました。UOVには大きな影響はありませんが、SNovとMAYOはより大きな攻撃を受けます。なぜこの攻撃が注目すべきかというと、「これまで発見されなかったことに驚かされた」という比較的単純なアイディアに基づいているからです。では、パフォーマンスの話を戻して、ルートとSCTのUOVとその他のML-DSA-44を組み合わせた場合、わずか10kBとなります。これはFN-DSA-512に近いことになります。
それでは、メインイベントに目を向けましょう：
現在の構成を見ると、MAYO、特にSNnovaはパフォーマンスの面で優れているように見えます。昨年、SNIoTとMAYOはパフォーマンスで僅差でしたが、かなりの差がありました。
MAYOは、Rainbowを破った暗号学者によって設計されています。構造化された多変量スキームとして、セキュリティには慎重な精査が必要ですが、（壊れていないという仮定に基づいて）その有用性は非常に魅力的です。MAYOでは、署名とパブリックキーのサイズ間のきめ細やかなトレードオフが可能です。シンプルにするため、作成者は2つの具体的なバリアントを提案しました。バランス署名（454バイト）でパブリックキー（1.4kB）のサイズを持つMAYOoneと、216バイトの署名を持つMAYOtwoは、パブリックキーを管理可能な状態に維持します4.3kBです。検証時間は優れており、署名時間はECDSAよりは若干遅いものの、RSAよりははるかに優れています。両方のバリアントを合算すると、4.3kBしか見られません。これらの数値は昨年よりも少し高いものになっています。MAYOは、新たに発見された攻撃を考慮して再びパラメータを調整したためです。
競争を通して、SNOVAはMAYOよりも強い攻撃を受けてきました。SNnovaの対応はより攻撃的になってきています。パラメーターを微調整して調整するのではなく、攻撃に対抗してパフォーマンスを改善するために、スキームの内部に大きな変更を加えているのです。SNOVA（37、17、16、2）とSNova（24、5、23、4）を単純に組み合わせると、驚異的な2.1kBが追加されることになります。
高リスクではあるがはるかに小規模なSNovaと、保守的だものの遅いMAYOとの対話は、直面することになるでしょう。排除すれば、どちらもパフォーマンスが良く、今デプロイするにはリスクが高すぎます。Ran氏の新たなwedges攻撃は、多変量暗号分析の分野での結果としてまだ驚かされるようなもので、時間と時間が必要です。SNovaとMAYOの間で賞品を選ぶのは早すぎる上、競争を続けましょう。たとえ安全であると判明したとしても、どちらも2029年までに標準化される可能性は高くありません。つまり、ポスト量子認証への移行の初期段階でそれらに頼ることはできないということです。
話を戻して、ML-DSA-44の15kBは実際のところ、それほど悪いものなのでしょうか？
Cloudflareでは、毎秒平均1800万件程度のTLS接続が確立されています。それぞれをML-DSAにアップグレードするには2.1Tbpsが必要で、これは現在のネットワーク容量全体の0.5%に相当します。今のところ問題はありません。問題は、こうした余分なバイトがパフォーマンスにどのように影響するかということです。
ML-DSA-44でスワップするには、15kBの余分なコストがかかります。これは、今日の通常のハンドシェイクと比較すると大幅に多いですが、多くのWebページで提供されるJavaScriptやimagesに比べれば大したことはありません。重要なのは、ここで行う変更が、肥大化したWebサイトに使用されているか、タイムクリティカルなAPI呼び出しに使用されているかにかかわらず、すべてのTLS接続に影響を与えるということです。また、もう少し待つだけではありません。モバイル端末の受信にムラがある場合、その余分なデータが、ページを読み込めるか、接続がタイムアウトするかを左右する可能性があります。（肥大化についてですが、多くのアプリは驚くほど多くのTLSハンドシェイクを実行しています）。
鍵合意と同様に、パフォーマンスは唯一の懸念事項ではありません。私たちは、最初に接続が成功することを望んでいます。2021年、私たちはより大規模なポスト量子証明書をシミュレートするために、証明書チェーンを人工的に拡大する実験を実施しました。その結果をこちらにまとめます。重要なポイントは、一部のクライアントやミドルボックスは10kBを超える証明書チェーンを好まないということです。これは、単一の証明書の移行戦略では問題です。この方法では、サーバーは、いわゆる非重要な拡張機能に別のポスト量子証明書を含む単一の従来の証明書をインストールします。ポスト量子証明書をサポートしていないクライアントは、拡張子を無視します。この方法では、1つの証明書をインストールすると、互換性の問題を抱えるすべてのクライアントが即座に中断するため、始めからではありません。パフォーマンス側では、初期の輻輳ウィンドウにより、10kBでパフォーマンスの大幅な低下も見られます。
9kBは多すぎるか？TLSハンドシェイクの遅延は約15%となります。当社は、後者は機能可能だと感じましたが、理想とは程遠いものでした。このような減速は顕著であり、ポスト量子証明書のデプロイは手遅れになる可能性があるのです。
Chromeはより慎重で、TLSハンドシェイクの最大退回の目標として10％に設定しています。彼らの報告によると、ポスト量子鍵合意のデプロイにより、TLSハンドシェイク時間にすでに4%の遅延が発生しており、サーバーからクライアントへの1.1kB、クライアントからサーバーへの1.2kBが追加されています。この減速は、9kBで検出した15%よりも比例して大きいですが、これは、ダウンロード速度よりもアップロード速度が遅いことで説明できます。
TLSハンドシェイク時間の重視に対しては、反感を買っています。1つの引数は、セッション再開により、証明書を再度送信する必要性が軽減されるというものです。2つ目の引数は、一般的なWebサイトにアクセスするのに必要なデータが、ポスト量子証明書の追加バイト数を気にすることはありません。一例として、2024年の発表物に、Amazonの研究者たちが、データの多いTLS接続に対する大規模なポスト量子証明書の影響をシミュレートしています。彼らは、通常の接続は複数のリクエストと数百キロバイトを転送し、TLSハンドシェイクの遅延はわずかな範囲で消失すると主張しています。
しかし、1つの接続に対してセッション再開や数百キロバイトは一般的でしょうか？私たちが得たものを共有したいと思っています。Cloudflareでは、ブラウザやブラウザのようなクライアントによって開始される可能性の高いQUIC接続に焦点を当てています。少なくとも1つのHTTPリクエストを伝送するCloudflareのQUIC接続のうち、27%が再開であり、以前のTLS接続の鍵材料が再利用されるため、証明書を送信する必要がありません。再開されたQUIC接続を介してサーバーからクライアントに転送されるバイト数の中央値は4.4kBであり、平均は259kBです。非再開の場合、中央値は8.1kB、平均は583kBです。中央値と平均との大きな差は、データ量の多い接続のごく一部が平均を歪めることを示しています。実際、100kB以上の転送を行うQUIC接続はわずか15.5%に過ぎません。
現在（圧縮あり）の証明書チェーンの中央値は3.2kBです。つまり、再開されていないQUIC接続の半分以上でサーバーからクライアントに転送される全データのほぼ40%が証明書のためのものであり、ポスト量子アルゴリズムではさらに悪化しています。QUIC接続の大部分では、従来の署名のドロップイン代替手段としてML-DSA-44を使用すると、接続を通して送信されるバイト数は2倍以上になります。
一般的な接続で転送されるデータの大部分がポスト量子証明書のためだけに機能するとしたら、それはかなり評判がよくないように聞こえます。実際に重要なこと、つまり、ブラウジング体験（例：最大コンテンツの描画）と、これらの証明書がユーザーの月間データ上限から取るデータ量に基づいています。私たちは引き続き調査を行い、影響の把握に努めます。
インターネットをポスト量子認証に移行する道筋は、鍵合意と比べてはるかに明確ではありません。現在の認証にはるかに近いパフォーマンスを得ることができない限り、ポスト量子認証の大部分は無効のままだと予想されます。Qの日が近づいてからポスト量子認証を有効にすることは、現実的なリスクがあり、修正するのに手遅れになる可能性があります。そのため、ポスト量子認証をデフォルトでオンにできるほど高性能にすることが不可欠です。
当社は、署名の数を減らすためのさまざまなアイデアを検討しており、中間者を取り除くという目標を掲げています。 KEMTLS;追跡することが可能です。昨年、詳しく取り上げました。最も進められたのは、最後の一つ、Merkle Tree Certificates（MTC）です。この提案では、一般的な場合、ハンドシェイク署名以外のすべての署名が、800バイト以下の短いマークルツリー証明に置き換えられます。これにより、従来の証明書を使用するよりも実際に高速なポスト量子認証が可能になる可能性があります。Chromeと共に、年内に試してみる予定です。それについては、このブログ記事をお読みください。
長いにもかかわらず、このブログ記事では、TLSの移行についてしか触れていません。また、TLSでさえ、Encrypted ClientHello について議論していないため（忘れたわけではありません）、完全には取り上げていません。TLSは重要なことですが、インターネットのセキュリティを確保するための唯一のプロトコルキーではありません。その他の課題について簡単にご紹介したいのですが、詳しくは触れられません。特に課題の1つは、ドメイン名の解決のセキュリティを確保するDNSSECです。
鍵合意と署名は最も広く使用されている暗号化プリミティブですが、ここ数年、プライバシーパス/PAT、匿名認証情報、属性ベースのリンク不可能 トークン など、より高度なユースケースに対応するために、より難解な 暗号化の採用が見られます。 暗号化 に使用することにしました。これらの高度な暗号方式のほとんどについては、ポスト量子に代わる実用的な方法はまだありません。喜ばしいことに、ポスト量子匿名認証情報の大きな進歩がありました。
まとめると、量子時代に注目すべき移行対象は、鍵合意と証明書の2つです。
当社は、両側のソフトウェア更新のみを必要とするstore-now/decrypt later攻撃に対抗するために、ポスト量子鍵合意に移行することを推奨します。つまり、ソフトウェアやサービス全体でX25519MLKEM768を迅速に導入（リスト維持）しているため、すでにstore-now/decrypt-laterに対する安全性は確保されているかもしれません！ Cloudflare Radarでは、お使いのブラウザがX25519MLKEM768をサポートしているかどうかを確認できます。 Firefoxを使用している場合は、アクセス中にWebサイトのサポートを確認するための拡張機能があります。 Webサイトがそれをサポートしているかどうかをこちらからスキャンできます。 Wiresharkを使って、侵入先をチェックすることができます。
それらは単なるスポットチェックです。適切な移行には、暗号技術が使用されている箇所を特定する必要があります。ほとんどの組織は、最初に使用しているソフトウェア、サービス、外部ベンダーを追跡するのに苦労しているため、これは非常に困難な課題です。アップグレードが難しいシステムや、外部依存関係のあるシステムもありますが、多くの場合は簡単です。実際、多くの場合、すでに完了していることを知るのに多くの時間を費やすことになります。
何をすべきかを決めることが作業の大部分であるため、最初のマイルストーンとしてそれを分割することも魅力でしょう。まず詳細なインベントリを作成し、いわゆる暗号化部品表（CBOM）のようなものです。在庫がそれ自体で目的となるようではいけません。外から目を向ける必要があるのです。ほとんどのケースは簡単です。1つのケースで移行する方法がわかったら、コンテキストを切り替えるのを待たず、すぐに実行してください。だからといってスピードが速くなるというわけではありません。これはマラソンではなくマラソンですが、開始することでどれだけの土俵を整備できるかに驚かされることでしょう。
証明書。このブログを書いている2025年10月時点では、ポスト量子証明書の最終基準はまだ定められていません。解決にそれほど時間がかからないことを願っています。しかし、ポスト量子証明書に備えるために、今できることはたくさんあり、後悔することはないでしょう。ソフトウェアを最新の状態に保ちます。証明書の発行を自動化する。複数の証明書をインストールできることを確認する。
プロトコルの固定化が心配な場合は、待つ理由はありません。最終的なポスト量子標準は、草案と大きく異なることはないでしょう。今日、暫定的な実装（または大規模なダミー証明書）でテストできます。
ポスト量子への移行は、かなりユニークです。一般的に、暗号化が破られると、それは突然、あるいは徐々に、しばらくの間無視するのが簡単になります。どちらの場合も、最終的には移行が急減します。量子の脅威により、多くの暗号技術を置き換える必要があることは確かですが、時間もあります。面倒な作業ではなく、これを機会と捉えていただければ幸いです。私たちは、ほとんど触れない多くのシステムをメンテナンスしなければなりません。今は、単なるホットフィックスではなく、過去の選択を見直す機会です。
少なくとも、今すぐ始めればなおさらです。移行が進められますが、何か問題に遭遇しましたら、ask-research@cloudflare.comまでご連絡ください。