CRYPTREC暗号リストにPQCの署名を追加へ 意見募集は11月11日まで

政府の調達で参照する「CRYPTREC暗号リスト」に、量子コンピュータでも破られにくい署名の方式が加わる見通しです。総務省・デジタル庁・経済産業省は2026年10月27日、リストの改定イメージを示し、11月11日までの意見募集を始めました。

社内の暗号の規程や、官公庁向けの仕様書でこのリストを引いている会社にとっては、どの表の、どの強さまでを認めるかを書き分けるきっかけになります。すぐに設定を変える話ではありません。ただ、2035年以降も使うシステムを今から設計するなら、この改定が基準になります。

3月の改定で空いていた署名の欄が埋まる

CRYPTREC暗号リストのうち「電子政府推奨暗号リスト」は、2026年3月の改定で2つの表に分かれました。従来の暗号を載せた表1（現行暗号リスト）と、量子コンピュータへの耐性が確認された暗号を載せる表2（耐量子計算機暗号（PQC）リスト）です。

もっとも、3月の表2に載った公開鍵暗号は、鍵共有のML-KEMだけでした。署名のML-DSAとSLH-DSAは、安全性と実装性能の評価が終わり次第載せる予定（2026年度を想定）とされ、ほかにも保留にした課題が残っています。そこでCRYPTRECは7月に「耐量子計算機暗号（PQC）リスト検討タスクフォース」を設け、10月23日までの5回の会合で残りの課題を話し合いました。今回の改定イメージは、その結果です。

表2の説明の文には、「Category 3以上の利用を推奨する。」の一文が加わります。暗号利用モードとメッセージ認証コードには単独のカテゴリーを付けず、組み合わせる暗号のカテゴリーに従うとしました。組み合わせる相手は、表2に載った暗号に限ります。

争点は128ビット相当の方式を載せるか

カテゴリーは、米国NISTがPQCの標準化の公募で示した、強さの物差しです。Category 1なら、128ビットの鍵のブロック暗号を総当たりで探すのと同じくらいの手間が、攻撃に要ります。Category 3は192ビット、Category 5は256ビットの鍵に当たります。Category 2と4は、ハッシュ関数の衝突を探す手間が基準です。

CRYPTRECは、表2をPQCへの移行が終わったあとも長く使う暗号のリストと位置づけています。一度載せると、外すときに政府の調達や相互運用に影響が出ます。暗号の強さの基準では、128ビットのセキュリティは2040年までは「利用可」、2041年からは「移行完遂期間」となり、2051年からは順に「利用不可」になります。政府システムのPQCへの移行は原則2035年が期限なので、128ビット相当を「推奨」してよいかが問われました。

改定イメージでの扱いは、方式ごとに分かれています。

ML-DSA-44のカテゴリーは、鍵を作るときに使う乱数生成器の強さで変わります。192ビット以上ならCategory 2、それ未満ならCategory 1です。政府システムの調達では乱数生成器の強さまで把握しにくいとして、192ビット以上を必須にはしていません。米国のCNSA 2.0はML-DSAをML-DSA-87に限っていますが、CRYPTRECは目的と対象が違うとして、同じ制限は設けない考えです。

今回の意見募集で特に意見を求めているのは、この署名のCategory 1・2の扱い、つまりML-DSA-44とSLH-DSAの128ビットの方式を載せるかどうかです。ML-DSAとSLH-DSAは、CRYPTRECの安全性評価がまだ終わっておらず、改定の中身は確定していません。

確定までに残る課題

• ML-DSAとSLH-DSAの安全性評価は、まだ終わっていません。米国の標準（FIPS 204・205）の方式で、評価は2026年度中に終わる予定です。
• 従来の暗号とPQCを組み合わせるハイブリッド構成をどう扱うかは、タスクフォースの課題に挙がっていましたが、改定イメージには書かれていません。
• 暗号の強さの基準（暗号強度要件の設定基準）は見直す予定で、当面、表2の公開鍵暗号にはこの基準を当てはめません。
• 改定の時期は示されていません。意見を踏まえてCRYPTRECがあらためて検討し、安全性評価の結果と合わせて改定するとしています。

影響を受けるのは、リストを規程や仕様書で引く会社

いちばん関わりが深いのは、官公庁や自治体にシステムや製品を納める会社です。調達の仕様書では、電子政府推奨暗号リストに載った暗号を使うよう求められることがあります。CRYPTRECは、2035年以降も使う予定のシステムは表1ではなく表2を参照して整備することになるとみています。今から設計するシステムは、ちょうどこれに当たります。

社内の暗号の規程で、使ってよい暗号の基準としてこのリストを引いている会社も関係します。「電子政府推奨暗号リストに載ったもの」とだけ書いた規程は、3月の改定から表1と表2の両方を指すようになりました。改定後の表2にはCategory 1・2のML-DSA-44も入るので、移行の目標をCategory 3以上に置くなら、規程にそう書き分ける必要があります。

一方、クラウドやSaaSを使うだけで、暗号の方式を自社で選ばない会社に、すぐの影響はありません。このリストは政府の調達のための参照で、民間に使うことを義務づけるものではないからです。とはいえ、量子コンピュータへの備えは、使っている製品やサービスの側で進みます。何がいつ切り替わるかを把握しておく意味はあります。

今から進める段取りと、意見の出し方

1. 社内の規程と仕様書のひな形を、「CRYPTREC」「電子政府推奨暗号」の言葉で検索します。見つかったら、表1と表2のどちらを指すか、強さの下限をどう書くかを書き出しておきます。改定の確定を待たずにできる作業です。
2. 暗号を使っている所を一覧にします。署名なら、サーバー証明書、コード署名、文書の電子署名、VPNの認証、DNSSEC。鍵共有なら、TLSやVPNの通信です。方式と鍵長、製品の版、サポートの期限を書き、2035年以降も使うものに印を付けます。
3. 製品の会社に、ML-KEMとML-DSAへの対応の予定を問い合わせます。対応するなら、ML-DSA-44・65・87のどれを使うのかも聞きます。改定イメージは、できる限り65か87を使うよう求めています。
4. 意見を出すなら、11月11日（水）24時までに出します。

TLSの鍵共有は、製品の側で先に切り替えが進んでいます。Java 27が登場TLS 1.3の「耐量子」ハイブリッド鍵交換を既定で有効にや、Google Meetが耐量子暗号に対応、設定不要で会議の保護を強化のように、利用者が何もしなくても変わる例もあります。一覧を作るときは、こうした「いつの間にか変わった所」も版で押さえておくと、あとで説明がつきます。

意見は、e-Govのパブリック・コメントのフォームから出すのが基本です。メールと郵送も受け付けますが、総務省は、意見の提出を装った不審なメールが送られるのを防ぐため、できる限りe-Govで出すよう求めています。

書くときは、①ML-DSA・SLH-DSAについての意見と、②そのほかの意見を分け、改定イメージの何ページのどの部分への意見かを明記します。会社や団体の意見は名前と一緒に公表されることがあり、匿名を望むならその旨を書き添えます。

「証明書でML-DSA-44を使う予定がある」「128ビットの方式でないと動かない機器がある」。自社の製品や利用の状況から、そうした具体的な事情を示せるなら、それが今回の論点を決める材料になります。