CRYPTREC暗号リストとは？3区分と鍵長基準

調達仕様書のレビューで、アルゴリズム名だけが並び、肝心の鍵長がどこにも書かれていない文書に出会ったことがあります。
その場では通っても、後日AESの解釈がベンダーごとに割れ、評価軸のすり合わせがもつれた経験から、暗号は名前だけで選ぶものではないと痛感しました。
CRYPTRECは、日本の電子政府調達で参照すべき暗号の基準枠です。
ただし見るべきなのは一覧表だけではなく、推奨・推奨候補・運用監視の3リストと、鍵長基準を定めるLS-0003-2022R1のセットです。
実際、既存VPN装置の棚卸しでは3DESが残ったまま運用され、64ビットブロック暗号の上限を意識しない設定が放置されていました。
この記事では、この3区分を一文で説明できるところまで整理し、2024年の更新注記と2025年のPQC動向を混同せずに押さえたうえで、暗号棚卸しやRFP作成・評価で何を確認すべきかを具体的に掴めるようにします。

CRYPTREC暗号リストとは何か

用語を分解

CRYPTRECはCryptography Research and Evaluation Committeesの略称で、日本の電子政府で使う暗号を評価・監視し、実装や運用の方針を整理するための取り組みの名称です。
名称だけ見ると「委員会の集合体」に見えますが、読む側にとっての要点はもっとシンプルで、電子政府の調達で暗号をどう選ぶかを、日本語で実務に落とし込んだ基準群だと捉えると全体像がつかめます。

出典として CRYPTREC の公式資料（LS-0001／LS-0003 の原文PDF）や改定告知ページを参照してください（例: CRYPTREC公式サイト:、デジタル庁: 筆者は公式PDFを開いたら、本文の表に飛びつく前にまず注記と凡例を読む癖をつけています。
暗号の文書は、表の一行だけ追うと意味を取り違えやすいからです。
実際、この順番に変えてから、アルゴリズム名だけを見て「使える」と早合点する場面が減りました。

この二層構造で見ると、CRYPTREC暗号リストは「店頭に並ぶ作品名の一覧」、鍵長基準は「どの版を選ぶかを決める仕様書」のような関係です。
作品名だけで注文すると限定版なのか通常版なのか分からないのと同じで、暗号も名前だけでは調達条件として足りません。
実務で仕様書を読むとき、表の左側にあるアルゴリズム名と、別文書にある鍵長条件を頭の中で一枚に重ねる感覚が必要になります。

専門用語は初出に原語併記（例）

この手の文書は、日本語だけ読んでいると似た言葉が並んで見えます。
そこで有効なのが、初出で原語を一緒に置いて意味の輪郭を固定する読み方です。
たとえば電子政府推奨暗号リストは英語で e-Government Recommended Ciphers と呼ばれ、いま参照の中心に置く暗号群です。
推奨候補暗号リストは英語で Candidate Ciphers と呼ばれ、安全性や実装性能の確認は済んでいても、利用実績や普及の面で一段手前にいる候補群です。
運用監視暗号リストは英語で Monitored Ciphers と呼ばれ、新規採用の主役ではなく、既存システムとの互換性維持を念頭に継続利用を認める枠です。

この3つを映画の配役でたとえるなら、電子政府推奨暗号リストが現行作品の主役、推奨候補暗号リストが次回作の主役候補、運用監視暗号リストが過去作とのつながりを保つために登場するベテラン俳優、という並びです。
どれも名前が載っているから同じ重み、という読み方はここでは通用しません。
区分が違えば、調達での扱いも変わります。

専門用語の原語併記は、英語資料や製品仕様書と突き合わせるときにも効きます。
候補だけ読むと曖昧でも、Candidate Ciphersと置けば「推奨そのものではないが、評価対象として位置づいている」と理解が安定します。
逆に、日本語だけで流して読むと、推奨候補監視の温度差が平板になりがちです。

鍵長まわりの用語も同様です。
リスト本文が方式名の選定表なら、暗号強度要件（Security Strength Requirements）はその方式に対して必要な強度を与える条件表です。
ここを外すと、アルゴリズム名がリストに載っていても、指定した鍵長が基準外なら、電子政府推奨暗号リストの暗号技術を使っているとは扱われません。
前のセクションで触れた「AESとだけ書いてあって解釈が割れた」状況は、まさにこの二段目が抜け落ちた状態でした。

注記の読み方にも、原語や正式名称を押さえる意味があります。
64ビットブロック暗号の扱いなどは、アルゴリズム名だけ見ていると古い方式が「まだ載っている」と誤解しがちですが、注に入る条件まで読むと風景が変わります。
たとえば同一鍵で暗号化できる上限が 2^20 ブロックという条件は、64ビットブロックなら約8.39MiBです。
文章で見ると抽象的でも、データ量に置き換えると印象が変わります。
少し大きめのファイル転送や連続通信なら、あっという間に届く範囲です。
筆者がPDFの注記を先に読むのは、こうした「表だけでは穏やかに見えるが、条件まで読むと運用の前提が厳しい」箇所を見落としたくないからです。

つまり、CRYPTREC暗号リストを理解する第一歩は、名称を正しくほどくことです。
CRYPTRECは組織・評価プロジェクトの名前で、電子政府における調達のために参照すべき暗号のリストはその成果物の中核です。
そして、そのリストはどの方式を選ぶかだけで完結せず、どの鍵長で使うかという別文書と組み合わさって、はじめて調達の基準として読める形になります。

なぜ日本に推奨暗号リストが必要だったのか

2000-2003: 初版の誕生

CRYPTRECが必要になった背景には、電子政府の整備が進むなかで、「どの暗号を採用すれば安全なのか」を各調達案件ごとにばらばらに判断するには限界があった、という事情があります。
暗号は数学の話であると同時に、実装と運用の話でもあります。
机上では強く見える方式でも、実装しにくかったり、既存システムとつながらなかったりすれば、政府全体の基準にはなりません。
そこで2000年度、電子政府の安全性確保を目的としてCRYPTRECが組織化されました。
出発点からして、研究者向けの純粋な評価プロジェクトではなく、行政システムで現実に使える参照基準を整える取り組みだったわけです。

この流れの節目になったのが、2003年2月20日の初版電子政府推奨暗号リストの公表です。
ここで示されたのは、単に「安全そうな暗号の名前を並べた名簿」ではありません。
電子政府の調達や設計で、何を基準に選ぶかをそろえるための共通言語でした。
いわば、バラバラの楽器で演奏していた現場に、ようやく同じ譜面台が置かれたようなものです。
各府省やベンダーが独自流儀で暗号を選び続けると、調達の比較も、保守の継続性も、将来の更新も噛み合いません。
そのズレを抑えるために、実用可能な「参照基準」が必要でした。

この時期からCRYPTRECが、安全性評価だけでなく、適切な実装法・運用法の検討まで射程に入れていた点も見逃せません。
電子政府では、暗号アルゴリズムそのものが強ければ終わりではなく、調達仕様書に落とし込めること、複数ベンダー間で解釈がそろうこと、長期運用に耐えることまで含めて基準化する必要がありました。
だからこそ、日本に推奨暗号リストが要ったのです。

2013: 3区分への改編

2013年には、このリストの考え方が一段成熟し、現在につながる3区分の枠組みへ改められました。
旧体系の初版は2013年3月1日で、電子政府推奨暗号リスト推奨候補暗号リスト運用監視暗号リストという整理が制度化されます。
ここでの転換点は、「安全か危険か」の二択だけでは、現実のシステム移行を扱いきれないと明確になったことです。

改編の理由をたどると、利用実績、普及状況、そして互換性維持という観点を、選定基準として明文化する必要があったと読めます。
安全性や実装性能が確認されていても、まだ利用実績が薄い方式は、いきなり電子政府全体の主軸には据えにくい。
一方で、過去に広く使われてきた方式は、新規採用の中心から外れても、既存システムとの接続やデータ互換のために、ただちにゼロにはできません。
この現実をきちんと制度の中に入れたのが、2013年改定の意味でした。

筆者が2010年代後半に官民連携プロジェクトの要求定義に関わったときも、この発想の重みを身にしみて感じました。
会議では安全性の話だけなら早くまとまるのに、実際には「既存装置とつながるか」「複数社で同じ解釈になるか」「現場に導入実績があるか」の三つで議論が止まります。
暗号方式の名前より、その方式をめぐる相互運用性と利用実績のほうが、案件全体の進み具合を左右する場面が少なくありませんでした。
2013年の3区分化は、そうした実務の摩擦をあらかじめ制度の言葉に置き換えた整理だと見ると、ぐっと腑に落ちます。

この改編によって、リストは「今すぐ中核として参照するもの」「将来の有力候補」「互換性維持のため監視しながら扱うもの」に分かれました。
電子政府の調達に必要だったのは、単純な合否表ではなく、時間軸を含んだ運用の地図だったのです。

2023-2024: 現行枠組みと更新

現行の電子政府における調達のために参照すべき暗号のリストは、2023年3月30日に初版が公表されました。
名称からもわかる通り、焦点はあくまで「電子政府における調達」であり、研究論文のランキング表ではありません。
安全性を確保しながら、実装・運用面も含めて行政の現場で参照できる基準として整え直したのが、この現行枠組みです。
3区分の考え方自体は2013年から継承しつつ、文書体系を現在の調達実務に合わせて整理した形です。

この2023年改定はデジタル庁から公表され、意見募集では4件の提出がありました。
件数だけ見れば大きな数字ではありませんが、暗号の基準文書は派手な話題になりにくい一方で、実際には調達仕様、製品選定、既存資産の延命判断にまで波及します。
静かな改定に見えて、現場への影響は広い。
暗号リストの更新がニュースサイトのトップを飾ることは少なくても、行政システムの裏側では配役表の差し替えに近い動きです。

その後の更新として押さえておきたいのが、2024年5月16日の改訂です。
このタイミングでは、署名DSAと64ビットブロック暗号の3-key Triple DESに関する注が追加されました。
ここでも見えてくるのは、リストが固定された「正解集」ではなく、運用条件や注意点を含めて手入れされる基準だということです。
前のセクションで触れた通り、アルゴリズム名だけでは判断が完結しないという性格は、こうした更新履歴にも表れています。

なお、近年の論点としてPQCも存在感を増していますが、現行リストそのものが直ちに耐量子計算機暗号中心へ組み替わったわけではありません。
2025年3月にはCRYPTREC 暗号技術ガイドライン（耐量子計算機暗号）2024年度版が公開され、別建ての整理として動きが見える段階です。
ここでも、日本の推奨暗号リストが担ってきた役割は一貫しています。
新技術の期待だけで突っ走るのではなく、安全性、実装性、利用実績、互換性を見比べながら、電子政府の現場で使える基準へ落とし込むこと。
そのための土台として、CRYPTRECのリストは更新され続けています。

3つのリストの違いを整理する

電子政府推奨暗号リスト

3区分のうち、実務でまず基準線になるのが電子政府推奨暗号リストです。
一文で覚えるなら、電子政府での利用を推奨する中核リストという位置づけです。
調達仕様書や提案書で暗号方式を選ぶ場面では、まずここに載っているかどうかが出発点になります。

この「推奨」は、単に理論上安全という意味だけではありません。
安全性と実装性能が確認され、利用実績や今後の普及見込みまで含めて、行政の現場で主軸に置けると整理されたものです。
たとえばAESやRSAのように、名前を見ただけで多くの関係者が共通理解を持ちやすい方式は、こうした中核リストの考え方と相性がよい典型です。
暗号は強ければ何でも同列、という世界ではなく、複数ベンダーが同じ仕様書を読み、同じ実装イメージにたどり着けることまで求められます。

ここで混同しやすいのが、アルゴリズム名と採用判断の距離感です。
推奨リストにあるから採用候補として筋が通るのであって、逆に言えば、ここにない方式を主役に据える場合は、なぜその選択が必要なのかを別途説明しなければなりません。
中核リストとは、暗号の「正解一覧」というより、調達現場で話を前に進めるための共通言語に近い存在です。

推奨候補暗号リスト

推奨候補暗号リストは、安全性・性能は確認済みだが、実績や普及状況などの面から候補にとどまるリストです。
ここがいちばん誤読されやすいところで、「候補」と書かれていても、安全性評価や実装性能が不足しているという意味ではありません。
むしろ、技術としては見られている。
ただし、電子政府全体の主軸として置くには、利用実績や広がり方がまだ十分とは言い切れない、という整理です。

筆者が入札審査で実際に議論を聞いたときも、ここが争点になりました。
ある提案で、候補リストの方式を主要方式として前面に出していたのですが、技術者側は「安全性と性能には問題がない」と評価していました。
その一方で、調達や運用の担当者は「導入後に他社提案との比較が難しくならないか」「普及が進んでいない方式を中核に据えて保守体制を組めるか」と立ち止まりました。
採否の議論で効いていたのは、暗号理論の優劣だけではなく、利用実績と普及状況だったのです。

この経験から見えてくるのは、候補リストは「使ってはいけない一覧」ではない一方、「推奨と同じ重みで扱える一覧」でもないということです。
案件の性格によっては十分に検討対象になりますが、主要方式に据えるなら、なぜ推奨リストではなく候補リストの方式を選ぶのか、その説明責任が一段増します。
映画のオーディションでいえば、実力は折り紙付きだが、まだ主演の定番ではない俳優に近い立場です。

運用監視暗号リスト

運用監視暗号リストは、互換性維持のため継続利用を容認するリストです。
ここでのキーワードは「容認」であって、「推奨」ではありません。
過去には安全性や実用性が確認されて広く使われたものの、新規採用の中心としては位置づけられなくなった方式が、既存システムとの接続やデータ互換の事情を踏まえて管理されています。

この区分がある理由は、現場のシステムが一斉に入れ替わるわけではないからです。
古い方式を使う相手機器、長期保存された暗号化データ、既存契約の制約などが残る以上、制度の側にも経過措置の器が必要になります。
2013年の3区分化が「時間軸を含んだ運用の地図」だといえるのは、このリストの存在があるからです。

ただし、ここは意味の取り違えが起きやすい箇所でもあります。

この注意点は、64ビットブロック暗号の扱いを考えると実感しやすくなります。
同一鍵で扱えるデータ量の上限は約8.39MiBにとどまり、100Mbps級の通信をそのまま流すと1接続で1秒もかからず届く大きさです。
つまり、昔は現実的だった設計が、いまの通信量や処理量ではすぐ苦しくなる場面があるということです。
運用監視は「まだ残っているから当面は向き合う」という整理であり、「安心して新規導入してよい」という意味には読み替えられません。

3区分の比較表

3つの区分は、言葉だけで追うと似て見えます。
実務では、位置づけ・安全性評価・利用実績・新規採用方針を横並びで見たほうが迷いません。
あわせて、CRYPTREC暗号リスト本体（LS-0001）と暗号強度要件（LS-0003）の役割分担も同じ表に置いておくと、「どの方式を選ぶ話」と「どの鍵長で使う話」が混線しません。

この表で見えてくるのは、3区分の差が「安全か危険か」だけではないことです。
推奨と候補の差は、主に利用実績や普及状況を含めて中核に据えられるかどうかにあります。
運用監視はそこからさらに一段違い、互換性維持のための継続利用容認という性格を持ちます。
制度上の棚が3段あるというより、主役、控え、退場準備中だが舞台裏でまだ役割が残る演者、くらいの温度差で捉えると、提案書や仕様書の読み解き方がぶれません。

アルゴリズム名だけでは足りない——鍵長基準の読み方

なぜ鍵長が重要か

暗号の名前だけを見て安心してしまうのは、映画のタイトルだけ見て中身を知った気になるのに似ています。
RSAECC（Elliptic Curve Cryptography）AES（Advanced Encryption Standard）といったアルゴリズム名はたしかに大枠を示しますが、実務で効いてくるのはどの鍵長で使うかです。
同じRSAでも、鍵長が違えば到達できる安全性は別物になります。

この違いは、試行空間が 2^n の形で増えていくと考えると直感的です。
鍵長が n ビットなら、総当たりで調べる候補はおおむね 2^n 個に膨らみます。
ビット数が少し伸びるだけで、攻撃側が相手にしなければならない世界は一気に広がります。
逆にいえば、アルゴリズム名が同じでも鍵長が足りなければ、看板は同じでも防御力は足りません。
AESとだけ書かれていても、AES-128なのかAES-256なのかで前提が変わるのはそのためです。

公開鍵暗号ではこの差がとくに見えやすく、RSAの 1024 ビットと 2048 ビット以降では、長期運用を前提にしたときの扱いがまるで違います。
楕円曲線暗号でも同じで、ECCとだけ書くのでは足りず、P-224なのかP-256なのかまで見ないと判断できません。
実際、暗号スイートの棚卸しで「アルゴリズム名のみ指定」と書かれた設計書に出会うと、ベンダーごとに解釈が割れます。
ある製品はRSA-2048を前提にし、別の製品はRSA-3072相当を見込み、さらに別の製品はECDSAの曲線選択まで含めて別回答になる。
名前だけでは、同じ舞台の上にいるようで立っている床が違うのです。

CRYPTREC の実務でも、この点は表と裏の関係ではっきり分かれています。
前のセクションで触れた通り、リスト本文は「どの方式を見るか」を整理し、鍵長の条件は別文書で読む構造です。
ここを飛ばしてアルゴリズム名だけ拾うと、「リストに載っている方式を使っているつもりなのに、実際は条件未達」という落とし穴に入ります。

LS-0003の読み方と典型シナリオ

鍵長を読むときの主役になるのがLS-0003-2022R1です。
正式には「暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準」で、アルゴリズム名の横に置くべき具体的なものさしだと捉えると腑に落ちます。
読み方のコツは、運用年限×脅威モデル×性能の3つを同時に見ることです。

運用年限は、その鍵や証明書をどれだけ先まで持たせたいかという時間軸です。
数年で更新される社内向けの証明書と、長く検証され続ける署名用途では、求める余裕が違います。
脅威モデルは、どの程度の攻撃者を想定するかという前提です。
広く公開されるサービスなのか、閉域に近い業務なのかで、同じアルゴリズムでも必要な強度の読み方が変わります。
性能は、CPU負荷、ハンドシェイク時間、鍵生成や署名検証のコストといった現場の現実です。
暗号は強ければそれで終わりではなく、回るシステムとして成立する必要があります。

筆者が証明書更新計画でRSA-2048からRSA-3072またはECDSA-P256への移行を検討したときも、この3点を並べて見ました。
RSA-3072は強度面の余裕を取りやすい一方、証明書サイズや処理負荷との相談が必要になります。
ECDSA-P256は性能面で魅力があり、ハンドシェイクの軽さを体感しやすい場面もありましたが、周辺機器や古い実装との相互運用性を詰める作業が別途必要でした。
机上では同じ「より強い鍵長への移行」でも、現場では計測結果と接続性の癖が判断を分けます。

具体例に落とすと、1024 ビットのRSAは長期用途の軸には置けません。
名前がRSAでも、長く守る前提の設計では外れます。
楕円曲線でも、今から採るならP-224よりP-256を優先する読み方になります。
対称鍵ではAES-128とAES-256のどちらを選ぶかが典型的な論点です。
AES-128は多くの用途で十分な強度と処理効率のバランスがよく、スループットを重視する場面で扱いやすい選択です。
いっぽうAES-256は、より長い保護期間や保守的な設計思想を取りたい場面で選ばれます。
ここでも「AES が載っているからよい」ではなく、「その用途なら 128 で足りるのか、256 を採るべきか」と読まなければ、設計の解像度が足りません。

そして見落とされがちなのが、基準に合わない鍵長は、リスト掲載暗号を利用しているとは見なされないという点です。
これは解釈上のニュアンスではなく、リスト本文と鍵長基準をセットで適用するという公式の注意そのものです。
RSAやAESという名前が一覧にあっても、採った鍵長がLS-0003-2022R1の条件から外れていれば、「掲載されている暗号を採用している」とは扱えません。
アルゴリズム名は出演者名、鍵長は配役です。
主役俳優の名前だけ合っていても、役が違えば同じ作品にはなりません。

よくあるNG設定例と是正

現場で頻出するNGは、まず「仕様書にアルゴリズム名しか書いていない」パターンです。
RSAAESSHA-2と並んでいるのに、鍵長やハッシュ長が落ちている。
これでは発注側は同じつもりでも、受注側は別々のものを実装できます。
筆者が見た案件でも、暗号スイートの棚卸しを進めるうちに、AESだけの記載がベンダーごとにAES-128とAES-256へ分岐し、公開鍵側もRSA-2048前提とECDSA-P256前提が混在していました。
文書の表面は整っていても、相互接続試験の段階で初めてズレが見える。
これは暗号方式の問題というより、記述粒度の問題です。

次にありがちなのが、「リストにRSAがあるから 1024 ビットでもよい」という誤読です。
これは方式名と鍵長基準を切り離して読んだときに起こります。
是正の仕方は単純で、方式名の右隣に採用鍵長を明記し、さらにその鍵長が長期運用なのか短中期の更新前提なのかを書き添えることです。
RSA-2048から一段先を見てRSA-3072へ上げるのか、署名性能や相互運用性を見てECDSA-P256へ寄せるのかは、その運用文脈まで含めて決まります。

楕円曲線では「ECC 採用」とだけ書くのも危険です。
P-224とP-256では読み方が違い、今の基準感覚ではP-256を選ぶほうが説明が通ります。
是正するときは、単に「ECC を使う」ではなく、「ECDSA-P256を署名用途に使う」と書くところまで下ろしたほうが、調達でも実装でも誤読が消えます。

対称鍵ではAES-256を選べば常に正解、という思い込みもズレの種です。
スループットや機器負荷との釣り合いを考えず一律に 256 を押し込むと、設計思想が見えなくなります。
AES-128で十分な保護期間と性能の両立が取れる用途もありますし、長めの保護期間や余裕を優先してAES-256を選ぶ場面もあります。
是正のポイントは、鍵長を「強い／弱い」の二択で語らず、用途・年限・処理量の条件つきで書くことです。

要するに、アルゴリズム名だけの記述は、地図に都市名だけ書いて縮尺を落としたようなものです。
実務で迷わない仕様書は、RSA-3072ECDSA-P256AES-128のように名前と鍵長が一体で書かれ、そこに運用年限と目的が添えられています。
CRYPTREC を読むときも同じで、リストに載っている名前を拾うだけでは半分です。
残り半分はLS-0003-2022R1で鍵長を読み切ったときに埋まります。

2024年更新版で押さえるべき注記

2024年5月16日の更新では、現行のCRYPTREC暗号リストに実務上見逃せない注記が足されました。
今回の読みどころは、単に「どの方式が載っているか」ではありません。
署名のDSA（Digital Signature Algorithm）と、64ビットブロック暗号としての3-key Triple DES（TDEA/3TDEA）に関する注記、そしてハッシュ長をどう見るかという運用条件の整理にあります。
映画で言えば、出演者一覧に後から小さく書き足された但し書きが、実は物語の解釈を変えてしまう場面に近いです。
本文の表だけを眺めていると通り過ぎてしまうのに、運用設計ではその一文が効いてきます。

64ビットブロック暗号の利用上限

今回いちばん具体的なのは、64ビットブロック暗号の同一鍵利用に上限があるという注記です。
同一鍵での暗号化は 2^20ブロックまで、同一鍵でのCMAC生成は 2^21ブロックまでという条件が明示されました。
64ビットブロックは1ブロック8バイトなので、暗号化の上限は約8.39MiB、CMAC生成の上限は約16.78MiBに相当します。

この数字は、紙の上ではまだ余裕があるように見えて、実運用へ持ち込むと急に表情が変わります。
8.39MiBは、バックアップやログ転送、ストリーム処理ではあっという間に通過する量です。
100Mbps級のデータ流量を想像すると、同一鍵の暗号化上限は1秒もかからず視界に入ります。
つまり、64ビットブロック暗号を「昔からあるからそのまま残す」という発想は、現代のデータ量と噛み合いません。

筆者がバックアップ媒体の暗号方式を見直したときも、ここが切り替え判断の分岐点でした。
XTS（XEX-based Tweaked CodeBook mode with ciphertext Stealing）を採る案は、ディスクや媒体単位の暗号化として筋が通っていましたが、実際にはモード名だけで決められません。
鍵をどう分離するか、実装側が要求する鍵の扱いに無理がないか、既存の復旧手順と衝突しないかを先に潰す必要がありました。
暗号方式の選定は、アルゴリズムそのものより鍵管理の設計で成否が決まる場面が少なくありません。
64ビットブロック暗号の上限注記は、その現場感覚を数字で裏打ちしたものと読むと腹落ちします。

DSAと3-key Triple DESへの注記

2024年5月16日の更新では、署名用途のDSAと64ビットブロック暗号の3-key Triple DESに注記が追加されました。
ここで読み取るべきなのは、「名前が載っているか」よりも、「その名前がいまどんな扱いを受けているか」です。
前者は一覧の読解で済みますが、後者は移行計画の話になります。

DSAは、公開鍵署名の歴史を語るうえで外せない方式です。
ただ、現場の選定軸としては、より新しい運用感覚と整合する方式が前面に出る流れが続いています。
今回の注記追加は、その空気を文章として可視化したものとして受け止めるのが自然です。
もっとも、なぜこのタイミングで明文化されたのか、背景理由を一次資料だけで細部まで断定するのは無理があります。
ここは踏み込みすぎず、「更新で明示された事実」までを押さえるのが筋です。

3-key Triple DESについては、レガシー機器や古い相互接続要件の中に残っていることがあります。
筆者も、長く使われた装置群の棚卸しで3DESの残存を段階的に止める運用計画を組んだことがありますが、実際に大変なのは停止宣言そのものではなく、どこにぶら下がっているかの洗い出しでした。
中継機器、古いVPN設定、保守用の閉域接続、更新が止まった管理画面用ライブラリまで掘っていくと、表の上では見えない依存関係が出てきます。
こうしたとき、運用監視という言葉は単なる分類名ではなく、「いま新規採用の中心には置かないが、消し方には順番がいる」という実務の温度を含んでいます。

ハッシュ長256ビット以上の意味

ハッシュ長（256ビット以上）の意味

ハッシュについては、256ビット以上という注記の意味をそのまま読んでおくのが肝心です。
ここでいう256ビットは、SHA-256のような出力長を念頭に置いた基準で、近年の安全性コンセンサスと素直に整合します。
古い文書ではSHA-1が残っていることもありますが、いまの調達や長期保管の文脈では軸になりません。

ここでも読み方のコツは同じで、「SHA-2系を使う」とぼかさないことです。
SHA-256を使うのか、より長い出力を前提にするのかまで書き切って初めて、設計の輪郭が立ちます。
アルゴリズム名だけでは足りないという前の節の話が、ハッシュ長の注記でもそのまま反復されています。

近年の流れ

近年の流れとして押さえたいのは、XTSやChaCha20-Poly1305の登場と普及を、今回の注記と直結した「理由」として断定しないことです。
ここは少し慎重に整理したほうがよく、一次資料で確実に言えるのは、より現代的な用途に合う方式やモードが広く使われるようになり、リストや周辺文書でも運用条件の明記が進んでいる、という経緯までです。

XTSはストレージ暗号化の文脈で存在感を持ち、ChaCha20-Poly1305はソフトウェア実装や通信路保護で定着しました。
どちらも、古い方式をそのまま延命するより、用途ごとに適した構成へ寄せていく流れの中で広がってきた名前です。
ただし、今回の2024年更新の注記がそれらの普及を直接の理由にしている、とまでは書けません。
そこは原文の但し書きから先を読み込みすぎないほうが正確です。

いま見えている輪郭はむしろ明快です。
64ビットブロック暗号には利用量の上限が明示され、署名のDSAと3-key Triple DESには追加注記が入り、ハッシュは256ビット以上が軸になる。
そこへXTSやChaCha20-Poly1305の普及という時代背景を重ねると、暗号の世界が「一覧表の掲載有無」から「用途ごとの現実的な運用条件」へ重心を移していることが見えてきます。
リストの更新履歴は短い文章でも、読む側がそこに運用の時間軸を入れると、ずいぶん立体的に見えてきます。

2025年以降の論点——PQCはどう関わるか

PQCガイドラインは別文書

2025年以降の論点を追ううえで、まず頭を切り替えておきたいのは、現行のCRYPTREC暗号リストとPQC（Post-Quantum Cryptography）の扱いを同じ紙面の延長で読まないことです。
ここは映画の続編とスピンオフの関係に少し似ています。
登場人物はつながっていても、筋立ては別です。
現行リストは、これまで見てきた3区分の枠組みで電子政府調達の参照先を示す文書であり、PQCの整理は別立てのガイドラインで進んでいます。

その動きがはっきり見えたのが、2025年3月に公開されたCRYPTREC 暗号技術ガイドライン（耐量子計算機暗号）2024年度版です。
名前に「2024年度版」と入っていても、公表のタイミングは2025年ですから、年号だけ眺めると少し戸惑います。
ただ、実務上の読み方は明快で、PQCの検討は現行リストを書き換える形ではなく、専用のガイドラインとして整理された、ということです。
新着情報や2025年のシンポジウム資料でも、この線引きは崩れていません。

この区別は、現場で資料を読む順番にも効いてきます。
従来方式の採用可否や現時点の調達上の位置づけは現行リストで確認し、耐量子計算機暗号への移行論点はPQCガイドラインで追う。
二つを混ぜると、「もう全部PQCに置き換わったのか」という誤読が起きます。
2025年時点で見えているのは、PQCが議論の中心に入ったことではあっても、現行リストそのものが直ちにPQC中心へ組み替えられたわけではない、という構図です。

WG継続

組織面でも、PQCが一過性の話題ではないことははっきりしています。
2025年のシンポジウム資料では、耐量子計算機暗号の技術調査ワーキンググループが2025〜2026年度に継続設置される流れが示されています。
2025年は「結論が出た年」というより、「評価軸を実務へ落とし込む作業が続く年」です。

ここでの論点は、単に候補アルゴリズムを眺めることではありません。
長期秘匿性が必要なデータをどう守るか、既存の公開鍵基盤とどう共存させるか、移行中の運用事故をどう避けるか、といった設計上の宿題が前面に出ます。
特に長寿命データを抱える部門では、いま解読されなくても、将来まとめて読まれる危険をどう扱うかが焦点になります。
いわゆる harvest now, decrypt later の懸念が、机上の話ではなくアーカイブ設計の条件として入ってくるわけです。

筆者も、10年以上の秘匿を前提にするデータを扱う部門で、PQCハイブリッド検証を試した場面があります。
そのときに見たのは、アルゴリズム名の新しさより、まず性能、次に相互運用性、そして標準化状況でした。
性能では、ハンドシェイクや鍵交換まわりの重さが既存基盤にどこまで乗るかを確認します。
相互運用では、TLS終端、HSM、認証局まわり、既存ライブラリとの接続で想定外の詰まりが出ないかを見ます。
標準化状況では、方式単体の安全性だけでなく、将来も実装が維持される見込みがあるかを測ります。
ここで効いたのが、ハイブリッド鍵合意（hybrid key establishment）という発想でした。
古典系とPQC系を並走させる構成なら、いきなり橋を架け替えるのではなく、仮設橋を並べながら本橋を造るような移行ができます。

現行リストとの住み分け

この先の実務で議題化しやすいのは、長期のconfidentialityを要求するデータをどこで切り分けるかです。
保存年限が短い行政文書と、長期間の秘匿を前提にする記録では、同じ公開鍵暗号の更新でも優先順位が変わります。
後者では、PQCの導入やハイブリッド鍵合意（hybrid key establishment）の検証、鍵長の見直しが現実的なテーマになります。

ただし、ここで住み分けを取り違えると話が急に雑になります。
現行のCRYPTREC暗号リストは、いま参照すべき方式を3つの区分で整理した文書です。
一方のPQCガイドラインは、耐量子計算機時代に向けた検討の地図です。
前者は現行運用の基準線、後者は移行戦略の設計図、と置くと見通しが立ちます。
PQCガイドラインが公開されたことは、量子計算を前提にした議論が制度の周辺ではなく中に入ってきたことを示しますが、それでも「今日の調達仕様が即日PQC前提に反転した」という意味にはなりません。

実際、現場で起きるのは一足飛びの置換より、用途ごとの分岐です。
たとえば短いライフサイクルの通信路では、現行リストに沿った方式を堅実に使い続ける判断が残ります。
対して、10年先、15年先まで秘匿を持ちこたえさせたいデータでは、いま暗号化して保管する時点からPQCを意識した設計が議題に上がります。
こうした温度差を無視して「PQC時代だから全部入れ替え」と考えると、技術より先に運用が破綻します。
2025年以降の論点は、PQCを採るか採らないかの二択ではなく、どのデータとどの経路から先に量子耐性の射程へ入れるか、その順番をどう切るかに移っています。

民間企業はCRYPTRECをどう読むべきか

参照の基本姿勢

CRYPTRECは電子政府調達のための基準枠ですが、民間企業にとっても十分に役立つ“読み筋”があります。
理由は単純で、暗号方式を選ぶときに見るべき論点が、政府と民間でまったく別物になるわけではないからです。
安全性、実装実績、運用上の制約、移行のしやすさ。
この並びは、社内システムでもSaaS連携でも、ほぼ同じように効いてきます。

ただし、ここでやってはいけないのが、一覧をそのまま社内標準へ貼り付ける読み方です。
電子政府向けの参照リストは、あくまで調達の基準線です。
民間ではそこに、自社システムの寿命、取引先や既存機器との互換性、標準化の進み具合、そして脅威モデルを重ねて判断する必要があります。
たとえば保存年限が短い業務データと、長期秘匿を前提にした設計データでは、同じ「安全な方式を選ぶ」という話でも優先順位が変わります。

筆者が現場でよく見たのは、「推奨リストにあるから採用」「載っていないから不採用」という二択で止まってしまう読み方でした。
実際には、そこから先にある運用条件まで読まないと仕様は閉じません。
鍵長をどう置くか、どのモードで使うか、どのプロトコル上で動かすか、どこまで既存互換を残すか。
暗号はアルゴリズム名だけで完結する部品ではなく、舞台装置まで含めて初めて意味を持ちます。
映画の配役だけ決めても、脚本と舞台が空白なら上演できないのと同じです。
前述の通り、LS-0001とLS-0003を突き合わせて読む前提に立つと、「方式名だけ拾って終わりにする」運用では不十分だと実感できます。
方式の位置づけと鍵長・強度条件は別レイヤーにあるため、民間で参照する際もこの二段読みを崩さないことで、仕様の解釈違いによる事故を減らせます。
前述の通り、LS-0001とLS-0003を突き合わせて読む前提に立つと、この“丸写しでは足りない”感覚がつかめます。
方式そのものの位置づけと、鍵長や強度条件は別レイヤーに置かれているからです。
民間で参照する際も、この二段読みを崩さないほうが事故が減ります。

RFP・調達の書き方

RFPや調達仕様で実務上いちばん効くのは、暗号要件を「アルゴリズム名」だけで書かないことです。

RFPや調達仕様で実務上いちばん効くのは、暗号要件を「アルゴリズム名」だけで書かないことです。
仕様に入れるべきなのは、アルゴリズム名、鍵長、運用条件の3点セットです。
運用条件には、利用モード、データ量の上限、鍵更新の前提、接続先プロトコルの条件まで含めます。
たとえば「AESを使う」ではなく、「AESをどの鍵長で、どのモードで、どの通信路で、どこまでのデータ量を前提に使うか」まで落として初めて、発注側と受注側の解釈がそろいます。

筆者は以前、RFP雛形を横断で見直したときに、鍵長未指定の記述が驚くほど多い時期にぶつかりました。
アルゴリズム名だけ並んでいるので、一見すると要件が立派に見えるのですが、ベンダーごとに解釈が割れ、レビュー段階で毎回差し戻しが起きていました。
そこでテンプレート側に、鍵長とモードを必須記入にする是正条項を入れたところ、見積もりの前提がそろい、後工程の混乱が目に見えて減りました。
調達文書は文学ではないので、余白が美徳になる場面はほとんどありません。

推奨候補暗号リストに載る方式を採る場合は、仕様書の書きぶりも一段丁寧にする必要があります。
安全性や性能の観点は通っていても、普及や相互運用の面で本命前の位置づけにあるためです。
この場合は、なぜその候補を選ぶのか、どの用途に限定するのか、将来の切替先をどう見ているのかを文章で残しておくと、後任者が読んでも判断経緯が途切れません。
単に「候補だから先進的」と書くのではなく、採用理由と移行計画を対で書く。
ここを省くと、数年後に“誰の判断で入ったのか分からない方式”が組織に残ります。

64ビットブロック暗号のように運用条件に厳しい注記が付くものは、RFPの時点で上限管理まで書いておかないと危険です。
同一鍵での暗号化上限は 2^20 ブロックで、データ量に直すと約 8.39 MiBです。
少し大きめのファイル転送や継続的な通信では、思ったより早く天井に届きます。
CMAC生成でも同一鍵の上限は 2^21 ブロック、約 16.78 MiBです。
こうした条件は「古い方式だから一応残す」という曖昧な扱いと相性が悪く、上限、鍵更新、用途制限まで仕様へ埋め込まないと運用で破綻します。

長期運用と互換性の判断

民間企業がいちばん悩むのは、新規採用の妥当性より、既存資産をどこまで残すかです。
運用監視暗号リストに入るものは、その象徴的な存在です。
ここにある方式は、互換性維持のための継続利用を前提に読むべきで、新規構築の主軸として据える対象ではありません。
社内で残すなら、「残す理由」と「いつまで残すか」を同時に決める必要があります。

このときは、リスク説明、影響範囲、縮退計画、期限の4点をセットにすると判断がぶれません。
たとえば、特定の周辺機器だけが古いTLSに依存しているなら、影響範囲はその系統に限定できるのか、代替経路はあるのか、ファーム更新か機器更改か、期限はいつか、まで書き出します。
互換性のために残す暗号は、保守契約の自動延長のように漫然と延命させると、いつのまにか“前提条件”へ化けます。

筆者がこの痛みを強く感じたのは、TLS 1.0 と RC4 の廃止対応を進めたときでした。
サーバ側の設定変更だけなら話は早いのですが、実際に詰まったのは周辺機器のファーム更新です。
複合機、計測機器、組み込み端末のような“通信の脇役”が古い暗号前提で止まり、全体の切替日程を押し戻しました。
主役のサーバは走る準備ができているのに、脇役が舞台袖から出てこない。
長期運用では、こういう場所がボトルネックになります。

標準化状況も見逃せません。
安全性評価だけでは、数年後にライブラリや製品実装が追随しているかまでは読めないからです。
長寿命システムでは、いま導入できることより、将来も保守し続けられることのほうが効く場面があります。
PQCのように今後の主戦場が広がる領域では、方式単体の新しさより、標準、実装、運用手順がどこまで整っているかで採否が分かれます。
民間でCRYPTRECを読むときも、この時間軸を忘れないほうが現実的です。

すぐにできるチェックリスト

実務で回しやすいのは、暗号の棚卸しを“製品名ベース”ではなく“列ベース”で持つ方法です。
資産台帳に近い発想で、システムごとに暗号方式、鍵長、プロトコル、ライブラリの版を並べます。
これだけで、見えていなかった不整合が急に姿を現します。
とくにOpenSSLの版とTLSバージョン、Java実行環境と利用可能スイートの関係は、障害の火種になりやすい部分です。

最低限そろえたい列は、次の形です。

1. システム名または機器名
2. 利用している暗号方式
3. 鍵長
4. 利用プロトコル（TLSバージョンなど）
5. 暗号ライブラリや実行基盤のバージョン
6. 新規採用か既存互換かを検討する
7. 置換予定の有無と期限

この一覧があると、LS-0001で方式の位置づけ、LS-0003で鍵長条件を照合する定期運用へつなげられます。
月次や四半期の運用会議で“脆弱性情報が出たら見る資料”にするより、平常時の棚卸し表として回しておいたほうが効きます。
暗号の問題は、事件が起きた瞬間に初めて台帳を作ろうとしても遅いからです。

チェックの観点も、難しく考えすぎなくて構いません。
新規案件なら推奨リスト相当を起点にしているか、候補採用なら理由と移行計画があるか、運用監視相当の方式を残しているなら期限があるか。
この3点がそろうだけで、仕様レビューの密度は一段上がります。
暗号の議論は抽象語が多くなりがちですが、実務では「何を、どの条件で、いつまで使うか」に翻訳できたものだけが残ります。

まとめ

キーポイントの箇条書き

CRYPTRECはプロジェクト名で、実務で照合する対象はCRYPTREC暗号リストです。読む単位を取り違えないだけで、仕様レビューの迷子が減ります。

• リストは推奨、推奨候補、運用監視の3区分で役割が分かれます。新規採用の起点、条件付きの検討対象、互換性維持を前提にした残置対象という整理で捉えると判断がぶれません。
• アルゴリズム名だけでは足りず、鍵長基準まで読んで初めて採否が決まります。2024年の更新は注記の確認を促す合図で、2025年以降のPQC動向は別文書で追う、という住み分けで見るのが実務向きです。
• 表現も同じで、「絶対安全」や「使ってはいけない」と断言するより、現時点のコンセンサスと一次資料に沿って、用途、期限、移行計画まで書くほうが現場では効きます。

次のアクション

読むだけで終えず、自組織の台帳に落とし込むのがこのテーマの本番です。
まずLS-0001で方式を棚卸しし、LS-0003で鍵長条件を確認し、運用監視に当たるものが残っていないかを洗い出す。
長期運用の案件はPQCガイドラインも視野に入れて、来週の定例で暗号棚卸しを議題に上げるところまで進めると、この記事の学びが実務に変わります。