--- title: "耐量子暗号とは：ML-KEMの仕組みとOpenSSL・SSHでの確認手順【2026年】" url: "https://www.issoh.co.jp/tech/details/19033/" published: 2026-10-29 updated: 2026-10-29 categories: ["セキュリティ"] publisher: "株式会社一創" --- # 耐量子暗号とは：ML-KEMの仕組みとOpenSSL・SSHでの確認手順【2026年】 耐量子暗号（PQC、耐量子計算機暗号）は、量子コンピュータを使っても効率よく解く方法が見つかっていない数学問題にもとづく公開鍵暗号です。2026年10月27日には、総務省・デジタル庁・経済産業省がCRYPTREC暗号リストの改定案（PQC対応）の意見募集を始め、同じ日に米NISTが移行期限をまとめたNIST IR 8547の最終版を公開しました。本記事では、NIST標準のML-KEM・ML-DSA・SLH-DSAの役割、国内外の期限、OpenSSL 3.5とOpenSSH 10系で対応を確かめるコマンドと設定例を、2026年10月28日時点の一次情報で整理します。 ## まとめ：耐量子暗号は鍵交換から切り替え、署名と証明書は2030年前後に備える 耐量子暗号の中心は、鍵共有のML-KEM（FIPS 203）と、署名のML-DSA（FIPS 204）・SLH-DSA（FIPS 205）です。急ぐべきは鍵交換で、今の通信を保存しておき将来解読する攻撃に備える必要があります。TLSならX25519MLKEM768、SSHならmlkem768x25519-sha256というハイブリッド方式が、OpenSSL 3.5とOpenSSH 10.0で既定になりました。 期限は、NIST IR 8547最終版が従来の公開鍵暗号を2030年後に非推奨、2035年後に使用不可としています。日本政府も原則2035年までの移行を目指します。まずOpenSSLとOpenSSHの版を上げて鍵交換を耐量子にし、証明書とコード署名は暗号の棚卸しを済ませてから計画的に移すのが現実的な順番です。 ## 耐量子暗号の仕組み：RSAと楕円曲線が破られる理由とNIST標準の3方式 最初に、何が危なくて何に置き換えるのかを押さえます。量子コンピュータそのものの原理は[量子コンピュータとは？仕組み・方式・実用化の現在地を実装目線で解説する技術ガイド](https://www.issoh.co.jp/tech/details/13586/)で扱っています。 ### ShorのアルゴリズムでRSAと楕円曲線暗号が解かれる理由と今収集し後で解読する脅威 RSAは素因数分解、楕円曲線暗号（ECDH・ECDSA）は離散対数問題の難しさに安全性の根拠を置いているのです。大規模な誤り耐性量子コンピュータでShorのアルゴリズムを動かすと、どちらも多項式時間で解けることが知られています。内閣官房の[政府機関等における耐量子計算機暗号（PQC）への移行について（中間とりまとめ）](https://www.cas.go.jp/jp/seisaku/pqc/pdf/report%5F202511.pdf)は、RSA-2048を現実的な時間で解くには100万物理量子ビット以上が必要とし、実現時期の予測は難しいと書いています。 それでも今動く理由は「今収集し、後で解読する（HNDL）」攻撃です。TLSで鍵交換した通信を記録しておけば、何年後かに鍵交換を解いて中身を読むことが可能です。10年後も秘密にしたい医療・金融・設計データを送るシステムは、量子コンピュータの完成を待たずに鍵交換を替える必要があります。AESなどの共通鍵暗号はGroverのアルゴリズムで安全余裕が減るだけなので、鍵長を256ビットに寄せれば足ります。両者の違いは[公開鍵暗号方式と共通鍵暗号方式の違いとは？](https://www.issoh.co.jp/column/details/13485/)が詳しいです。 ### ML-KEM・ML-DSA・SLH-DSAの役割と鍵・署名サイズの比較 NISTは2024年8月に3つの標準を公開しました。[FIPS 203](https://csrc.nist.gov/pubs/fips/203/final)が鍵共有のML-KEM、[FIPS 204](https://csrc.nist.gov/pubs/fips/204/final)が格子暗号の署名ML-DSA、FIPS 205がハッシュ関数だけに頼る署名SLH-DSAです。実装で効いてくるのはサイズの差です。 | 方式 | 用途 | 代表パラメータ | 公開鍵（バイト） | 暗号文・署名（バイト） | | ---------- | --- | ----------------- | -------- | ----------- | | ML-KEM | 鍵共有 | ML-KEM-768 | 1,184 | 1,088 | | ML-DSA | 署名 | ML-DSA-65 | 1,952 | 3,309 | | SLH-DSA | 署名 | SLH-DSA-SHA2-128s | 32 | 7,856 | | X25519（従来） | 鍵共有 | － | 32 | 32 | 鍵交換で増える通信量は、1回の接続につき約1KBという程度です。署名は証明書チェーンの各段に載るため、ML-DSAでも1本あたり数KB膨らみます。SLH-DSAは安全性の前提が保守的な反面、署名が大きく、TLSの証明書よりもファームウェア署名のような回数の少ない用途に向きます。 ### 量子鍵配送（QKD）やハイブリッド暗号方式と耐量子暗号を取り違えない区別 名前が似ている3つを分けておきます。量子鍵配送（QKD）は光ファイバーと専用装置で鍵を送る物理的な仕組みで、ソフトウェアの更新では入りません。耐量子暗号は普通のCPUで動くアルゴリズムで、ライブラリを更新すれば使えます。 もう1つの「ハイブリッド」は2つの意味で使われます。公開鍵で共通鍵を運ぶ従来の構成と、X25519とML-KEMを同時に使って片方が破られても安全を保つ鍵交換です。前者の実装と2つの語義の違いは[ハイブリッド暗号方式とは？仕組みとPython実装・PQC移行を解説](https://www.issoh.co.jp/column/details/3572/)にまとめています。本記事で扱うX25519MLKEM768は後者です。 ## 2026年10月の2つの公表：CRYPTREC改定案とNIST IR 8547最終版 期限と採用すべき方式は、2026年10月27日に国内と米国で同時に動きました。発注側の調達要件になるため、受託開発でも押さえておく必要があります。 ### CRYPTREC暗号リスト改定案でPQCリストに加わる署名方式とCategory 3推奨 [総務省の報道資料](https://www.soumu.go.jp/menu%5Fnews/s-news/01cyber01%5F02000001%5F00308.html)によると、意見募集は2026年10月27日14時から11月11日24時までです。[CRYPTREC暗号リスト](https://www.cryptrec.go.jp/list.html)には2026年3月の改定で「表2 耐量子計算機暗号（PQC）リスト」が加わっていますが、署名方式は空欄でした。[改定イメージ（別添2）](https://www.soumu.go.jp/main%5Fcontent/001098192.pdf)で比べると、変わる箇所は次のとおりです。 | 技術分類 | 2026年3月版の表2 | 改定案 | | -------- | ---------------------- | --------------------- | | 署名 | 掲載なし | ML-DSA・SLH-DSAを追加 | | 鍵共有 | ML-KEM-768、ML-KEM-1024 | 変更なし（ML-KEM-512は載せない） | | 共通鍵・ハッシュ | AES-192・256、SHA-384など | 共通鍵・ハッシュの方式を追加 | | 認証暗号 | 掲載なし | ChaCha20-Poly1305を追加 | 表の追加対象の内訳は、署名がML-DSA-44・65・87とSLH-DSAの192・256系、共通鍵・ハッシュがCamellia-192・256とSHAKE256などです。認証暗号のChaCha20-Poly1305はCategory 5での追加です。 表の説明文に加わるのは「Category 3以上の利用を推奨する」という推奨条件です。[改定イメージの考え方（別添3）](https://www.soumu.go.jp/main%5Fcontent/001098193.pdf)は、2035年以降も使うシステムは表1ではなく表2を参照して整備することになると書いています。案の段階ですが、今から設計する案件はML-KEM-768以上とML-DSA-65以上を基準にしておくと、確定後に作り直さずに済みます。 ### NIST IR 8547の2030年非推奨・2035年禁止と日本政府の移行目標 [NIST IR 8547の最終版](https://csrc.nist.gov/pubs/ir/8547/final)は、RSA・ECDSA・EdDSA・DH・ECDHを2030年後に非推奨（deprecated）、2035年後に使用不可（disallowed）とし、ML-KEM-768を既定のパラメータとして推奨しています。米連邦の重要システムには、鍵確立を2030年12月31日、署名を2031年12月31日までに耐量子へ移す期限も示されました。 日本は先の中間とりまとめで、政府機関等は原則2035年までの移行を目指し、2026年度に工程表を作るとしています。2026年10月28日時点で、[関係府省庁連絡会議のページ](https://www.cas.go.jp/jp/seisaku/pqc/index.html)に工程表の掲載は見当たりません。金融業界での受け止めは[金融システムの技術トレンド：生成AI・トークン化預金・耐量子暗号・勘定系クラウドの現在地](https://www.issoh.co.jp/column/details/7450/)で扱っています。 ## OpenSSL 3.5で耐量子暗号を試す手順：鍵交換の確認とML-DSA証明書の作成 ここからは手元で確かめる手順です。コマンドはOpenSSL 3.5系の構文で書いています。 ### OpenSSLのバージョンとML-KEMを含むアルゴリズム一覧を確かめるコマンド [OpenSSL 3.5の告知](https://openssl-library.org/post/2025-04-08-openssl-35-final-release/)によると、3.5は2025年4月8日公開のLTSで、2030年4月8日までサポートされ、ML-KEM・ML-DSA・SLH-DSAを収録しています。[ダウンロードページ](https://openssl-library.org/source/)の最新は4.1.0（2026年10月23日）と3.5.9（同9月29日）などで、3.0系はすでに一覧にありません。まず版と対応アルゴリズムを確認します。 ``` # 版の確認（3.5系以降なら耐量子の3方式が使える） openssl version # 鍵カプセル化（KEM）の一覧。ML-KEMとX25519MLKEM768などのハイブリッドが並ぶ openssl list -kem-algorithms # 署名アルゴリズムからML-DSAとSLH-DSAだけを抜き出す openssl list -signature-algorithms | grep -i -E "ml-dsa|slh-dsa" ``` 3.0系のままのサーバーでは、どちらの一覧にもML-KEMやML-DSAは出ません。3.5 LTSと4.x系のどちらへ上げるかは[OpenSSL 4.0は非LTS｜最新4.0.3・EOL一覧と3.5 LTSの選び方](https://www.issoh.co.jp/tech/details/11733/)で比べています。 ### s\_clientで接続先がX25519MLKEM768の鍵交換に応じるかを確かめる手順 [OpenSSL 3.5の変更点](https://openssl-library.org/post/2025-03-11-openssl-3.5-alpha/)には、TLSの既定のキーシェアをX25519MLKEM768とX25519にしたとあります。接続先が耐量子の鍵交換に応じるかは、鍵交換グループを1つに絞って接続すれば判定できます。 ``` # 鍵交換グループをX25519MLKEM768だけに絞る（TLS 1.3） openssl s_client -connect www.example.com:443 -tls1_3 -groups X25519MLKEM768 -brief < /dev/null # 比較用：従来のX25519だけに絞る openssl s_client -connect www.example.com:443 -tls1_3 -groups X25519 -brief < /dev/null ``` 1つ目でハンドシェイクが成立すれば、相手はX25519MLKEM768に対応しています。失敗して2つ目だけ通るなら、サーバー側のOpenSSLが古いか、グループの設定で耐量子が外されています。TLS 1.3の鍵交換の流れは[TLSとは？SSLとの違い・仕組みとバージョン選定を実装者向けに解説](https://www.issoh.co.jp/tech/details/13318/)を参照してください。 ### ML-DSA-65の鍵ペアと自己署名証明書をgenpkeyとreqで作る検証手順 署名側は、検証環境で証明書を1枚作るとサイズ感がつかめます。Category 3のML-DSA-65を使います。 ``` # ML-DSA-65の秘密鍵を作る openssl genpkey -algorithm ML-DSA-65 -out mldsa65.key # 検証用の自己署名証明書（30日） openssl req -x509 -new -key mldsa65.key -subj "/CN=pqc-test.example" -days 30 -out mldsa65.crt # 署名アルゴリズムを確認し、ファイルサイズを従来の証明書と比べる openssl x509 -in mldsa65.crt -noout -text | grep "Signature Algorithm" ls -l mldsa65.crt ``` 自己署名なので、この証明書はブラウザーの検証には通りません。[別添3](https://www.soumu.go.jp/main%5Fcontent/001098193.pdf)の整理でも、ML-DSAはX.509とCMSではRFC化済みですが、TLSのハンドシェイク署名に使う仕様はまだInternet-Draftの段階です。使い道は社内のmTLSやコード署名の検証、ペイロード増加の見積もりに限られ、本番のサーバー証明書は当面RSAかECDSAのまま運用します。 ## nginxとOpenSSHを耐量子の鍵交換へ切り替える設定例と互換性の落とし穴 鍵交換の切り替えは、ライブラリの更新と設定の見直しでほぼ終わります。止まる原因の多くは、過去に書いた固定値です。 ### nginxのssl\_ecdh\_curveを固定していると耐量子の鍵交換が無効になる理由 [nginxのssl\_ecdh\_curve](https://nginx.org/en/docs/http/ngx%5Fhttp%5Fssl%5Fmodule.html)の既定値は`auto`で、リンクしたOpenSSLに組み込まれたリストを使います。OpenSSL 3.5以降とリンクしていれば、何もしなくてもX25519MLKEM768が候補に入ります。ところが、以前のTLS設定ガイドに従って`prime256v1:secp384r1`のように固定していると、耐量子のグループは使われません。 ``` # nginxがリンクしているOpenSSLの版を確認 nginx -V 2>&1 | grep -i openssl # /etc/nginx/conf.d/tls.conf：ハイブリッドを先頭に置き、非対応クライアント向けに従来方式を残す ssl_protocols TLSv1.2 TLSv1.3; ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1; ``` ECDSA証明書を使うサーバーは、証明書の曲線（多くはprime256v1）をリストから外すとハンドシェイクが失敗します。固定値を書くなら従来の曲線を後ろに残し、`nginx -t`で構文を確かめてから再読み込みします。 ### OpenSSH 10系の既定鍵交換と10.1から出る耐量子でない接続の警告 [OpenSSHのリリースノート](https://www.openssh.org/releasenotes.html)では、9.9（2024年9月19日）でmlkem768x25519-sha256が加わり、10.0（2025年4月9日）で既定になりました。10.1からは耐量子でない鍵交換で接続すると警告が出て、10.6（2026年10月6日）ではsshd側にも同じ`WarnWeakCrypto`が加わり、既定で記録します。 ``` # クライアントが対応する鍵交換からML-KEM系を探す ssh -Q kex | grep mlkem # 実際に交渉された鍵交換を確かめる ssh -v server.example.com exit 2>&1 | grep "kex: algorithm" # ~/.ssh/config：更新できない古い機器だけ警告を止める Match host legacy.example.com WarnWeakCrypto no-pq-kex ``` [OpenSSHの耐量子暗号のページ](https://www.openssh.org/pq.html)は、警告を止めるなら対象ホストを限ることを勧めています。全体で`WarnWeakCrypto no`にすると、更新漏れのサーバーに気づけなくなります。sshd\_configの`KexAlgorithms`を古い一覧で固定している場合も、nginxと同じ理由で耐量子が外れるので見直してください。版の確認と更新手順は[OpenSSHとは？最新バージョン10.6の確認方法とアップデート手順](https://www.issoh.co.jp/tech/details/10191/)にあります。 ### ClientHelloが1KB以上増えて古い中継装置が接続を切る失敗パターン X25519MLKEM768のキーシェアは、ML-KEM-768の公開鍵1,184バイトとX25519の32バイトで計1,216バイトです。従来のX25519だけのClientHelloは数百バイトなので、1つのTCPセグメントに収まらなくなる場合があります。 分割されたClientHelloを想定していない古いロードバランサーやWAF、TLS検査装置が経路にあると、ハンドシェイクの途中で接続が切れる場合があるのです。症状は「一部の拠点からだけつながらない」形で出るため、切り替え前に社内経路を含む検証環境でs\_clientの2つの接続を比べ、失敗したら`ssl_ecdh_curve`を従来の値に戻せるようにしておきます。Javaクライアントでも同じ論点があり、[Java 27とは｜非LTSの半年運用とG1・オブジェクトヘッダ既定化の影響](https://www.issoh.co.jp/tech/details/17712/)でTLS 1.3の耐量子ハイブリッド鍵交換の影響範囲を扱っています。 ## 耐量子暗号への移行を始める条件と今は見送ってよいシステムの線引き 全システムを一度に替える必要はありません。データの寿命と、暗号を誰が握っているかで順番を決めます。 ### 暗号インベントリで洗い出す対象と鍵交換・署名・保存データの優先順位 中間とりまとめは、移行対象を把握するために利用中の暗号モジュールと方式の一覧（クリプト・インベントリ）を作るよう求めています。受託開発の現場で洗い出す対象は、TLSを終端する機器とそのOpenSSLの版、SSHの接続先、アプリが直接呼ぶ暗号API、証明書の発行元と有効期限、署名済みの成果物です。 優先順位ははっきりしています。1番目は、10年以上秘密にしたいデータが流れる通信の鍵交換です。2番目は、更新に何年もかかる組み込み機器のファームウェア署名です。サーバー証明書やログイン認証は、解読された時点で破られる性質なので後回しにできます。どこで何の暗号を使っているか自社で把握しきれない場合は、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)の範囲にTLS設定と暗号の棚卸しを含めて依頼すると、移行対象の一覧が手に入ります。 ### ML-KEM-512やML-DSA-44を新規採用せず、移行を見送ってよい場面 新規開発でML-KEM-512を選ぶ理由はありません。CRYPTRECの改定案は載せない方針で、NISTも768を既定にしています。ML-DSA-44は改定案に載りますが、長期保護が要る用途では65か87を強く推奨する注記付きです。自前で格子暗号を実装するのも見送ります。耐量子暗号はサイドチャネル対策の蓄積が浅いと中間とりまとめも指摘しており、OpenSSLなど保守されているライブラリに任せるべきです。 逆に、保存期間が数か月の社内データしか流れず、2030年より前に更改が決まっているシステムは、今すぐ手を入れなくて構いません。次の更改時にOpenSSL 3.5以降とOpenSSH 10系を条件にしておけば、鍵交換は自然に耐量子になります。 ## 耐量子暗号の導入前に開発・インフラ担当者からよく受ける質問と回答 移行の相談でよく出る質問を5つ取り上げます。 ### 耐量子暗号とポスト量子暗号、PQCは同じものですか？ 同じものです。英語のPost-Quantum Cryptography（PQC）の訳として、政府文書では「耐量子計算機暗号」、技術記事では「耐量子暗号」「ポスト量子暗号」が使われます。CRYPTRECの改定案も、表記は「耐量子計算機暗号（PQC）」のまま変えない方針です。量子力学を使って鍵を送る「量子暗号」や量子鍵配送（QKD）は別物で、専用の装置が要ります。 ### AESなどの共通鍵暗号も耐量子暗号に置き換える必要がありますか？ 方式の置き換えまでは要らず、必要な対応は鍵長の見直しです。NIST IR 8547は、共通鍵暗号の既存標準から離れる必要はないとしています。CRYPTRECの表2もAES-128を載せず、AES-192とAES-256だけを掲載しています。新しく設計する保存データの暗号化はAES-256を選び、TLSの暗号スイートもAES-256-GCMかChaCha20-Poly1305を残す構成にしておけば十分です。 ### 量子コンピュータはいつRSAを解けるようになりますか？ 確かな予測はありません。中間とりまとめは、2039年より前にRSA-2048を解ける量子コンピュータが実現する確率を5％未満とする研究と、15年以内の実現確率を39〜62％程度とする分析の両方を挙げ、時期の予測は難しいとしています。期限を決めているのは時期の予測ではなく、移行に10年以上かかることと、今の通信が保存されている事実です。 ### TLSのサーバー証明書もすぐにML-DSAへ切り替えるべきですか？ 今は急ぐ段階ではありません。TLSのハンドシェイク署名にML-DSAを使う仕様はIETFで策定中で、サーバー証明書の置き換えはブラウザーと公開CAの対応待ちです。署名は解読された時点で破られる性質なので、まず鍵交換を耐量子にし、証明書は公開CAの対応を待ってから移る順番で問題ありません。社内PKIで使う証明書は、ML-DSAで試験発行しておくと移行時の負荷を測れます。 ### 民間企業もCRYPTREC暗号リストに従う必要がありますか？ 法的な義務はありません。CRYPTREC暗号リストは電子政府の調達で参照する暗号の一覧です。ただし、官公庁や自治体、重要インフラ向けのシステムでは調達仕様に「電子政府推奨暗号リストに掲載の暗号を使う」と書かれることが多く、受託開発ではそのまま要件になります。改定案が確定すれば表2が参照先に加わるため、該当する案件はML-KEM-768以上を前提に設計しておくと安全です。 ## 関連記事 - [ハイブリッド暗号方式とは？仕組みとPython実装・PQC移行を解説](https://www.issoh.co.jp/column/details/3572/)：RSA-OAEPとAES-GCMの実装と、PQCハイブリッド鍵交換との語義の違いです。 - [金融システムの技術トレンド：生成AI・トークン化預金・耐量子暗号・勘定系クラウドの現在地](https://www.issoh.co.jp/column/details/7450/)：金融機関が耐量子暗号の棚卸しに着手する時期の考え方です。 - [TLSとは？SSLとの違い・仕組みとバージョン選定を実装者向けに解説](https://www.issoh.co.jp/tech/details/13318/)：X25519MLKEM768が載るTLS 1.3の仕組みを確認できます。 - [OpenSSL 4.0は非LTS｜最新4.0.3・EOL一覧と3.5 LTSの選び方](https://www.issoh.co.jp/tech/details/11733/)：ML-KEMを使うために上げるOpenSSLの系列選びです。 - [OpenSSHとは？最新バージョン10.6の確認方法とアップデート手順](https://www.issoh.co.jp/tech/details/10191/)：mlkem768x25519-sha256を既定にする10系への更新手順です。 --- 出典: [耐量子暗号とは：ML-KEMの仕組みとOpenSSL・SSHでの確認手順【2026年】]()（株式会社一創）