調べたことを書き散らしておく。ここが俺の日記帳なので！
Disclaimer
内容はできる限り正確な情報を提供するように努めていますが、正確性を保証するものではありません。
概要・用語・そもそもの話
PQCとは？
Post Quantum Cryptography, ポスト量子暗号
なぜPQCが必要なのか
"Harvest now, descrypt later(HNDL)"戦略で今抜き取られた情報が将来的に復号される可能性があるため。
量子コンピュータは今でも実験的なシステムがある程度動いているが、それらでは現状のRSA暗号は解読できないと思われている。下図の左下灰色の枠が現状の量子コンピュータが解読できると思われている暗号強度で、右側の赤破線が現在使われているRSA暗号が解読されると思われるボーダーライン。この灰色のエリアが広がる、イコール1エラーレートが現状の1/10ほどになり、かつQubit数が100万〜1000万くらいになるといよいよヤバいよ、という感じ。
出典: Landscape of Quantum Computing 2025
現時点でその将来(Years to Quantum, Y2Q, Q-Dayなどと呼ばれる)がいつ来るかはわからないが、2031年頃と予測する人もいる。異論(2045年以降)もある。
現状は実際に現行アルゴリズムが解読されるかどうかは関係なく、国が移行目標を勝手に決めつつある。
| 国/地域 | 計画完了 | 実装開始 | 完全移行 |
|---|---|---|---|
| オーストラリア | 2026年末 | 2028年末 | 2030年末 |
| 米国 | 進行中 | 進行中 | 2035年頃 |
| 英国 | 2028年 | 2031年 | 2035年 |
| カナダ | 2025年 | 2026年 | 2030年代初頭 |
| EU | 2026年 | 2027年 | 2030年代半ば |
出典: 【徹底比較】NIST標準ML-KEM/ML-DSA/SLH-DSAと各国のPQC動向を追う#タイムラインの国際比較
日本も2035年を移行目標として進めていくことを想定しているようだ(参考: 『政府機関等における耐量子計算機暗号（PQC）への移行について（中間とりまとめ）2025年11月 - 政府機関等における耐量子計算機暗号（PQC）利用に関する関係府省庁連絡会議』)
PQCに対応しなければいけない要素
TLSで暗号化しているところ。ブラウザからバックエンドのAPIサーバ、DBとの通信など、ほぼ全ての通信経路はPQCに対応する必要がある。
暗号化のために使用される証明書、CAもPQC対応のものに入れ替える必要がある。
現状利用できるPQCアルゴリズム(全て非対称鍵暗号アルゴリズム)
| 用途 | アルゴリズム | パラメータ | NISTセキュリティレベル | 公開鍵サイズ(byte) | 暗号文サイズ(byte) |
|---|---|---|---|---|---|
| TLSハンドシェイクなど | ML-KEM | ML-KEM-512 | NIST Level 1 | 800 | 768 |
| TLSハンドシェイクなど | ML-KEM | ML-KEM-768 | NIST Level 3 | 1184 | 1088 |
| TLSハンドシェイクなど | ML-KEM | ML-KEM-1024 | NIST Level 5 | 1568 | 1568 |
| デジタル署名 | ML-DSA | ML-DSA-44 | NIST Level 2 | 1312 | 2420 |
| デジタル署名 | ML-DSA | ML-DSA-65 | NIST Level 3 | 1952 | 3293 |
| デジタル署名 | ML-DSA | ML-DSA-87 | NIST Level 5 | 2592 | 4595 |
| デジタル署名 | SLH-DSA | DLH-DSA-128s | NIST Level 1 | 32 | 7586 |
| デジタル署名 | SLH-DSA | DLH-DSA-128f | NIST Level 1 | 32 | 17088 |
| デジタル署名 | SLH-DSA | DLH-DSA-256s | NIST Level 5 | 64 | 29792 |
- ML-KEM = 旧 Kyber。現在のアルゴリズム名で "ML-KEM" もしくは "KEM" ではなく、明示的に "Kyber" と付いているものは、NIST標準化の前のドラフト版をもとにした実装であることが暗示されている
- ML-DSA = 旧 Dilithium
- SLH-DSA = 旧 SPHINCS+
- NIST Levelが高いほど暗号強度が高いが、計算コストが上昇する
- 現状どのアルゴリズムも検証されているが、量子コンピュータによる実際に解読にどの程度耐性があるかはわからない
- 現状IETFで定義されてるのはハイブリッド方式（X25519MLKEM768等）のみ
上記は全て非対称鍵暗号アルゴリズム。
既存の対称鍵暗号アルゴリズムは鍵サイズが十分に大きければ(AESかつ256bit以上)量子暗号耐性があると考えられている。不安があれば鍵サイズを大きくすることで対応できる。例えばAES-256(NISTセキュリティレベル2)は量子コンピュータでの解読難易度はAES-128(NISTセキュリティレベル1)相当と言われている。
参考
- AESの鍵サイズとNISTセキュリティレベルの対応: https://quready.com/resources/nist-pqc-standards-guide/
- AES-256でも量子ではない通常のコンピュータでは解読に膨大な時間(数百万年レベル)かかると言われている。また解読成功報告はない: https://ja.wikipedia.org/wiki/Advanced_Encryption_Standard
ハイブリッドPQCとは
PQCと従来のRSA暗号を組み合わせて使う方法。過渡期の方法として優先的に実装が進んでいる。
- あくまで鍵交換時に使用される
- 共通鍵をPQCでくるんで、さらにRSAでくるむ
- 今のところPQCの暗号耐性が未知数なので、PQCだけに依存しないようにする
- 二重でくるんでいるので処理負荷は高い。でも鍵交換だけなので実質的な問題はないはず。問題なかったという報告もある
- 実際に使用されているのはIETFで定義されてる X25519MLKEM768 が大多数(参考)。互換性のために ML-KEM の前身の Kyber を使った X25519Kyber768Draft00 をサポートしている製品もある
PQCに対応しているライブラリやサービス
現状(2025年12月現在)純粋なPQCに対応している暗号化ライブラリはない。
ハイブリッド方式
特に注釈がないものは以下がソース
| 用途 | ソフトウェア/ライブラリ名 | X25519MLKEM768 | X25519Kyber768Draft00 |
|---|---|---|---|
| ブラウザ | Chrome/Edge | 131+ | 124-130 |
| ブラウザ | Firefox | 132+ | 124-130 |
| ブラウザ | Safari | 26+ | -- |
| Web/APIサーバ | nginx | with OpenSSL 3.5+/たぶんBoringSSLでもいける | with BoringSSL |
| Proxy/ロードバランサ | Envoy | with BoringSSL | with BoringSSL |
| 言語 | Node(Javascript) | 24.5.0+ | -- |
| 言語 | Go | 1.24+ | 1.23 |
| 言語 | Python | --(下記備考1参照) | --(下記備考1参照) |
| 汎用 | OpenSSL | 3.5.0+ | -- |
| 汎用 | BoringSSL | ok | ok |
| 汎用 | GnuTLS | ok | ok |
備考:
- いくつかのサイト(あえてリンクせず)では Python + OpenSSL 3.5.0+ でPQC対応の通信ができると書かれているが間違い。おそらく aws boto の独自実装とPython標準ライブラリ(cryptography)を混同していると思われる。もちろん外部ライブラリ(qcrypto, pqjwt, pqcryptographyなど)を使えば可能
- ブラウザであれば https://pq.cloudflareresearch.com/ を開くだけで対応有無を確認できる
アプリケーションは数が多すぎるのでギブアップ。各自調べてくれ。
クラウド側の対応(X25519MLKEM768だけ)
AWS先行って感じだけどぜんぜんカバレッジないので各社これからって感じ
終わりです
俺たちのたたかいはこれからだ！
知らんけど。
-
これも諸説ある。Michele MoscaはRSA-2048を解読するために必要なQubit数は数千万(10^7)〜10億(10^9)程度と推定している。この場合Q-Dayの到達はさらに延びる ↩
-
https://aws.amazon.com/jp/blogs/security/ml-kem-post-quantum-tls-now-supported-in-aws-kms-acm-and-secrets-manager/ ↩ ↩2 ↩3
-
https://qiita.com/nyamanana/items/7d48b9eb55e76ecbf3d6#4-aws-cloudfront--aws-waf ↩
-
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/secure-connections-supported-viewer-protocols-ciphers.html#secure-connections-openssl-rfc-cipher-names ↩
-
https://docs.aws.amazon.com/elasticloadbalancing/latest/application/describe-ssl-policies.html#:~:text=Security%20policies%20with,and%20X25519MLKEM768%20algorithms. ↩
-
https://aws.amazon.com/jp/about-aws/whats-new/2025/11/s3-post-quantum-tls-key-exchange-endpoints/ ↩
-
https://news.microsoft.com/ja-jp/2025/08/22/quantum-safe-security-progress-towards-next-generation-cryptography/ ↩
-
https://cloud.google.com/blog/ja/products/identity-security/announcing-quantum-safe-digital-signatures-in-cloud-kms ↩