CRYPTREC MT-1011-2022
資料１

2022年度 第１回 暗号技術検討会～

令令 和 ５ 年 ２ 月 2 7 日
和 ５ 年 ３ 月 ６ 日
メール開催

議事次第
１．議事
(1) 公募提案暗号の自主取下げ要望に対する取り扱いルールの策定並びに「ECDSA、ECDH及びSC2000」の取扱いについて【承認】(2) CRYPTREC暗号リストの改定について【承認】(3) 意見募集の実施方法及びその後の対応について【承認】配付資料一覧
資料１
資料２
資料３
資料４－１
資料４－２
資料４－３
資料５
参考資料１
参考資料２

議事次第・配付資料一覧
公募提案暗号の自主取下げ要望に対する取り扱いルールの策定
並びに「ECDSA、ECDH及びSC2000」の取扱いについて（案）【承認事項】
今次のCRYPTREC暗号リスト改定（旧“全面改定”）に至る主な経緯
CRYPTREC暗号リストの改定について（案）【承認事項】
CRYPTREC暗号リスト（現行版）
CRYPTREC暗号リスト（改定案）
意見募集の実施方法及びその後の対応について（案）【承認事項】
電子政府推奨暗号リスト掲載への推薦候補案について
暗号アルゴリズム利用実績調査報告

以上

資料２

公募提案暗号の自主取下げ要望に対する取り扱いルールの策定
並びに「ECDSA、ECDH 及び SC2000」の取扱いについて（案）2000 年度、2001 年度及び 2009 年度の暗号技術公募への提案会社である富士通株式会社より、自社が提案した暗号アルゴリズム（以下、「公募提案暗号」という。
）「ECDSA、ECDH 及び SC2000」について自主取下げの要望が寄せられた。一方、現在の CRYPTREC 暗号リストでは、ECDSA 及び ECDH
は「電子政府推奨暗号リスト」に、SC2000 は「推奨候補暗号リスト」に掲載されているが、公募提案
暗号の自主取下げ要望に対する扱いは規定されていない。
そのため、今回、公募提案暗号の自主取下げ要望に対する取り扱いルールを策定し、当該ルールに基づき、「ECDSA、ECDH 及び SC2000」の取り扱いを決定することとしたい。

【背景】
2020 年度の暗号技術検討会で移行ルールを策定した際、「推奨候補暗号リスト」に長らく存在し続ける暗号技術については今後普及する見込みが極めて低いと推測されることから、CRYPTREC 暗号リス
トへの掲載から 20 年を経過したものについては「その後に実施する最初の利用実績調査の結果によって十分な利用実績が確認できなかった場合にはリストから削除」するルールを導入した。
今回、公募提案暗号の自主取下げ要望が提案会社から申請されたが、2020 年度の移行ルールを策定した際の趣旨を踏まえると、「今後の普及が見込めない公募提案暗号」であると判断されるものについては、提案会社の意向により「推奨候補暗号リスト」からの削除を認めることができるようにすることが適切であると考えられる。

【審議事項 1】 公募提案暗号の自主取下げ要望に対する取り扱いルールの策定
提案会社からの自社の公募提案暗号の自主取下げ要望に対しては、以下の通り取り扱う。
1.

提案会社からの自社の公募提案暗号の自主取下げ要望に当たっては、別紙の「暗号技術取下げ申請書」により、CRYPTREC 事務局に申請する。

2.

申請を受けた CRYPTREC 事務局は、当該申請について、以下の判断基準を踏まえ、暗号技術活用委員会及び（暗号技術活用委員会において審議した上で）暗号技術検討会に対して付議する。


取下げ申請の承認は「推奨候補暗号リスト」に掲載されている自社の公募提案暗号のうち「今後の普及が見込めない公募提案暗号」であると判断されるものに限る

「電子政府推奨暗号リスト」及び「運用監視暗号リスト」に掲載されている公募提案暗号については既に「普及している公募提案暗号」として扱い、取下げ申請は却下する



ただし、前 2 項の基準にかかわらず、知的財産権の無償許諾や利用状況（今後の見込みを含む）などにより、
当該暗号技術の CRYPTREC 暗号リストへの掲載に伴う対応を CRYPTREC

事務局が自主的に管理すべきであると判断される場合には、取下げ申請を受けて、公募提案
暗号から事務局提案暗号に位置づけを変更する
3.

2.の付議内容について、暗号技術活用委員会において審議した上で、暗号技術検討会において審議し、以下のいずれかの決定を行う。
「推奨候補暗号リスト」から削除する

公募提案暗号から事務局提案暗号へ位置づけを変更した上で、CRYPTREC 暗号リストに掲載したままとする



CRYPTREC 暗号リストに掲載したままとする（公募提案暗号から事務局提案暗号への位置づけの変更は行わない）【審議事項 2】 「ECDSA、ECDH 及び SC2000」の取扱いについて
上記の取り扱いルールに基づき、富士通株式会社からの「ECDSA、ECDH 及び SC2000」についての自主取下げ要望に関し、以下の通り取り扱う。
なお、当該要望については、2022 年 12 月 14 日に開催された第二回暗号技術活用委員会において、
CRYPTREC での自主取下げルールの策定を前提として、暗号技術活用委員会としては当該要望に沿う方向で判断したとすることが了承されている。


ECDSA 及び ECDH については、「電子政府推奨暗号リスト」に掲載されており、かつ各種国際
標 準 等 で 規 格 化 さ れ て い る こ と か ら 、 CRYPTREC 暗 号 リ ス ト へ の 掲 載 に 伴 う 対 応 を
CRYPTREC 事務局が自主的に管理すべき暗号技術であると判断し、公募提案暗号から事務局提案暗号に位置づけを変更した上で、CRYPTREC 暗号リストに掲載したままとする

SC2000 については、「推奨候補暗号リスト」に掲載されており、かつ「今後の普及が見込めない
公募提案暗号」であると判断されることから削除する

以上

CRYPTREC 事務局宛

【別紙】

（送付先：info@cryptrec.go.jp）

暗号技術取下げ申請書
申請責任者
会社名・部署名 ○○○○○○○○
役 職○○○○○○○○

氏 名○○○○○○

印

このたび、「電子政府における調達のために参照すべき暗号のリスト(CRYPTREC 暗号リスト)」に掲載されている以下の暗号技術について、同リストからの取下げを申請いたします。

申請日： 20

年

月日

暗号技術名（複数列挙可）：

取下げ申請受理に関するCRYPTRECホームページでの公表

□ 可

□ 不可

CRYPTREC暗号リストからの削除時期の希望
注1）希望日は申請日の2ヶ月後以降としてください。
注2）CRYPTREC暗号リストからの削除有無を含め、希望通りにはならない場合もありますが、ご了承ください。申請を受けた対応内容については、決定次第、CRYPTREC事務局よりご連絡いたします。

□ 20 年月日希望□ CRYPTRECのスケジュールに任せる（原則として年度末頃になります）
取下げ申請の理由

備考・その他の連絡事項

連絡担当者
担当者氏名：
TEL:

所属・役職：
FAX:

e-mail:

以

上

資料３

今次のCRYPTREC暗号リスト改定（旧“全面改定”）に至る主な経緯

今次のCRYPTREC暗号リスト改定（旧“全面改定”）に至る主な経緯
１. リストの全面改定を実施、今後のリスト改定方針の大枠を決定（2012年度暗号技術検討会）

・2003年に策定した「電子政府推奨暗号リスト」を、「電子政府推奨暗号リスト」、「推奨候補暗号リスト」、「運用監視暗号リスト」の３リストで構成する「電子政府における調達のために参照すべき暗号のリスト（CRYPTREC暗号リスト）」に再構成。
・「CRYPTREC暗号リスト」の次回の全面改定は10年後を目途に実施する等、今後のリスト改定方針の大枠を決定。

２. 2023年目途のリスト改定方針を決定（2020年度暗号技術検討会）

・2023年目途のリスト改定に当たり、３リスト構成を維持する方針、技術分類の構成を維持する方針を決定。
・上記改定に当たり、暗号技術の公募は行わない方針を決定。

３. 2023年目途のリスト改定等に適用する新たな基準を決定（2021年度暗号技術検討会）

・「推奨候補暗号リスト」から「電子政府推奨暗号リスト」へ昇格させる暗号アルゴリズムを選定する際の、暗号アルゴリズムの利用実
績による選定基準（別紙１）を決定。
※ 上記基準決定後の「CRYPTREC 暗号リスト」移行ルールは別紙２のとおり。

４. 2023年のリスト改定に係る具体的改定内容を検討（2022年度暗号技術活用委員会）

・ 2022年度に暗号技術活用委員会が実施した暗号アルゴリズム利用実績調査の結果を踏まえ、暗号技術活用委員会において、「推奨候補暗号リスト」から「電子政府推奨暗号リスト」への昇格候補として暗号技術検討会に推薦する暗号アルゴリズム（別紙３）を決定。

上記経緯を踏まえ、暗号技術検討会において、「CRYPTREC暗号リスト」改定案をご審議いただきたい。

暗号アルゴリズムの利用実績による選定基準
考慮項目
採用実績

別紙１

選定目安
以下のいずれかを満たす場合、昇格の検討対象に含める。なお、採用実績は、
5年ごとに実施予定の大規模アンケート調査による「利用実績調査」

必要に応じて、事務局が（大規模アンケート調査によらずに）情報収集する「利用実態確認」
により確認するものとする。
① 利用実績調査の結果、電子政府推奨暗号リストに掲載されている 電子政府推奨暗号リスト掲載の（同一カテゴリの）暗号技（同一カテゴリの）暗号技術の採用実績と遜色がないことが確認さ 術の採用実績と同等以上の採用実績がある推奨候補暗号リれた場合
スト掲載の暗号技術を昇格検討対象とする。
② 利用実績調査又は利用実態確認の結果、電子政府システムや重要イ 必要に応じて、利用実績調査に代わって、各府省庁等へのンフラ等、日本の基幹システムにおいてすでに利用されていること 照会を実施し、照会結果（クローズドな利用を含め）を基が確認された場合に昇格検討対象を選定する。
利用実績調査又は利用実態確認の結果、③～⑤のいずれかが確認された 「複数」「利用者が多い（主要な）」というキーワードの場合：
両方を十分に満たし、明らかな採用促進が確認された場合③ 利用者が多い主要な汎用製品群の複数に搭載されるなど、明らかに には、必要に応じて、昇格検討対象とする。
※「複数」の意味は、必要条件として「2個以上が必要」と採用が進展していると判断された場合④ 利用者が多い主要なオープンソースソフトウェアの複数に搭載され いうことであって、「2個以上あればよい」という十分条件るなど、明らかに採用が進展していると判断された場合としての意味ではないことに留意⑤ 利用者が多い主要なサービスやプロトコルの複数で利用されるなど、明らかに採用が進展していると判断された場合

標準化実績 以下を満たす場合、昇格の検討対象に含める。
⑥ 利用実績調査の結果、電子政府推奨暗号リストに掲載されている 電子政府推奨暗号リスト掲載の（同一カテゴリの）暗号技（同一カテゴリの）暗号技術の採用実績と遜色がないことが確認さ 術の採用実績と同等以上の採用実績がある推奨候補暗号リれた場合
スト掲載の暗号技術は昇格検討対象とする。
3

CRYPTREC 暗号リスト移行ルール

別紙２

4

暗号技術検討会に推薦する暗号アルゴリズム
暗号アルゴリズムの技術分類
公開鍵暗号（署名）ハッシュ関数

暗号利用モード（秘匿モード）
認証暗号
エンティティ認証

推薦する暗号アルゴリズム
EdDSA
SHA-512/256
SHA3-256
SHA3-384
SHA3-512SHAKE128SHAKE256
XTS
ChaCha20-Poly1305
ISO/IEC 9798-4

別紙３

資料４－１
電子政府における調達のために参照すべき暗号のリスト（CRYPTREC 暗号リスト）の改定について（案）
電子政府における調達のために参照すべき暗号のリスト（CRYPTREC 暗号リスト、現在のリストは
資料４－２のとおり）の改定に関して、次のとおり改定する方針とし、当該改定案（資料４－３）に対する意見募集を実施することについて御審議いただきたい。
※ 資料４－２及び資料４－３の内容は、事前に資料２の内容が承認されたと仮定して作成している。

１．認証暗号 ChaCha20-Poly1305 の電子政府推奨暗号リストへの昇格
暗号技術活用委員会において実施された認証暗号 ChaCha20-Poly1305 に対する 2022 年度の暗号ア
ルゴリズム利用実績調査の結果(参考資料２参照) 及び 2021 年度に暗号技術検討会において承認された「暗号アルゴリズムの利用実績に基づく選定基準」（資料３別紙２参照）に基づく暗号技術活用委員会
からの提案 (参考資料１参照) を踏まえ、認証暗号 ChaCha20-Poly1305 を CRYPTREC 暗号リストの「推奨候補暗号リスト」から「電子政府推奨暗号リスト」に昇格する。
２．秘匿モード XTS の電子政府推奨暗号リストへの昇格
暗号技術活用委員会において実施された秘匿モード XTS に対する 2022 年度の暗号アルゴリズム利用実績調査の結果(参考資料２参照) 及び 2021 年度に暗号技術検討会において承認された「暗号アルゴ
リズムの利用実績に基づく選定基準」（資料３別紙２参照）に基づく暗号技術活用委員会からの提案 (参考資料１参照) を踏まえ、秘匿モード XTS を CRYPTREC 暗号リストの「推奨候補暗号リスト」から「電子政府推奨暗号リスト」に昇格する。
３．エンティティ認証 ISO/IEC 9798-4 の電子政府推奨暗号リストへの昇格
暗号技術活用委員会において実施されたエンティティ認証 ISO/IEC 9798-4 に対する 2022 年度の暗号アルゴリズム利用実績調査の結果(参考資料２参照) 及び 2021 年度に暗号技術検討会において承認された「暗号アルゴリズムの利用実績に基づく選定基準」（資料３別紙２参照）に基づく暗号技術活用委員
会からの提案 (参考資料１参照) を踏まえ、エンティティ認証 ISO/IEC 9798-4 を CRYPTREC 暗号リストの「推奨候補暗号リスト」から「電子政府推奨暗号リスト」に昇格する。
４．ハッシュ関数 SHA-512/256, SHA3-256, SHA3-384, SHA3-512, SHAKE128, SHAKE256 の電子政
府推奨暗号リストへの昇格
暗号技術活用委員会において実施されたハッシュ関数 SHA-512/256, SHA3-256, SHA3-384, SHA3512, SHAKE128, SHAKE256 に対する 2022 年度の暗号アルゴリズム利用実績調査の結果(参考資料２参照) 及び 2021 年度に暗号技術検討会において承認された「暗号アルゴリズムの利用実績に基づく選

定基準」（資料３別紙２参照）に基づく暗号技術活用委員会からの提案 (参考資料１参照) を踏まえ、
ハ ッ シ ュ 関 数 SHA-512/256, SHA3-256, SHA3-384, SHA3-512, SHAKE128, SHAKE256 を
CRYPTREC 暗号リストの「推奨候補暗号リスト」から「電子政府推奨暗号リスト」に昇格する。
５．署名 EdDSA の電子政府推奨暗号リストへの昇格
暗号技術活用委員会において実施された署名 EdDSA に対する 2022 年度の暗号アルゴリズム利用実績調査の結果(参考資料２参照) 及び 2021 年度に暗号技術検討会において承認された「暗号アルゴリズ
ムの利用実績に基づく選定基準」（資料３別紙２参照）に基づく暗号技術活用委員会からの提案 (参考資料１参照) を踏まえ、署名 EdDSA を CRYPTREC 暗号リストの「推奨候補暗号リスト」から「電子政府推奨暗号リスト」に昇格する。

資料４－２CRYPTREC LS-0001-2012R7

事前に資料２の内容が承認されたと仮定して作成

電子政府における調達のために参照すべき暗号のリスト（CRYPTREC暗号リスト）（現行版）
平成25年３月１日
デジタル庁・総務省・経済産業省（最終更新：令和●年●月●日）

電子政府推奨暗号リスト
暗号技術検討会 1 及び関連委員会（以下、「CRYPTREC」という。）により安全性及び実装性能が確認された暗号技術 2 について、市場における利用実績が十分であるか今後の普及が見込まれると判断され、当該技術の利用を推奨するもののリスト。
なお、利用する鍵長について、「暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準」 5の規定に合致しない鍵長を用いた場合には、電子政府推奨暗号リストの暗号技術を利用しているとは見なされないことに留意すること。
技術分類

暗号技術
DSA
ECDSA
RSA-PSS（注１）
RSASSA-PKCS1-v1_5（注１）
RSA-OAEP（注１）
DH

署名
公開鍵暗号
守秘
鍵共有
（注２）

64ビットブロック暗号
共通鍵暗号

ECDH
該当なし
AES
Camellia
KCipher-2

128ビットブロック暗号
ストリーム暗号

SHA-256
SHA-384
SHA-512

ハッシュ関数

CBC
CFB

秘匿モード
暗号利用モード
認証付き秘匿モード（注13）メッセージ認証コード

CTR
OFB
CCM
GCM（注４）
CMAC
HMAC
該当なし

認証暗号
1

デジタル庁統括官、総務省サイバーセキュリティ統括官及び経済産業省商務情報政策局長が有識者の参集を求め、暗号技術の普及による情報セキュリティ対策の推進を図る観点から、専門家による意見等を聴取することにより、デジタル庁、総務省及び経済産業省における施策の検討に資することを目的として開催。
2
暗号利用モード、メッセージ認証コード、エンティティ認証は、他の技術分類の暗号技術と組み合わせて利用することとされているが、その場合、CRYPTREC暗号リストに掲載されたいずれかの暗号技術と組み合わせること。
5
CRYPTREC, 暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準, https://www.cryptrec.go.jp/list.html

1ISO/IEC 9798-2
ISO/IEC 9798-3

エンティティ認証（注１）「政府機関の情報システムにおいて使用されている暗号アルゴリズムSHA-1及び
RSA1024に係る移行指針」（平成20年４月情報セキュリティ政策会議決定、平成24年 10 月 情 報 セ キ ュ リ テ ィ 対 策 推 進 会 議 改 定 ） を 踏 ま え て 利 用 す る こ と 。
https://www.nisc.go.jp/active/general/pdf/angou_ikoushishin.pdf（平成25年３月１日現在）（注２）

CRYPTREC暗号リストにおいて、64ビットブロック暗号により、同一の鍵を用いて暗号化する場合、220ブロックまで、同一の鍵を用いてCMACでメッセージ認証コードを生成する場合、221ブロックまでとする。

（注４）

初期化ベクトル長は96ビットを推奨する。

（注13） CRYPTREC暗号リスト掲載のブロック暗号を、認証付き秘匿モードと組み合わせて、「認証暗号」として使うことができる。

2

推奨候補暗号リスト
CRYPTRECにより安全性及び実装性能が確認され、今後、電子政府推奨暗号リス
トに掲載される可能性のある暗号技術 3 のリスト。なお、本リストに記載されている暗号技術を利用する際は、「暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準」 6の規定に合致する鍵長を用いることが求められることに留意すること。
技術分類
公開鍵暗号

暗号技術

署名
守秘

EdDSA
該当なし

鍵共有

PSEC-KEM（注５）
CIPHERUNICORN-E
Hierocrypt-L1
MISTY1CIPHERUNICORN-A
CLEFIA
Hierocrypt-3
Enocoro-128v2
MUGI
MULTI-S01（注７）64ビットブロック暗号（注６）

共通鍵暗号

128ビットブロック暗号

ストリーム暗号

ハッシュ関数

SHA-512/256
SHA3-256
SHA3-384
SHA3-512SHAKE128（注12）
SHAKE256（注12）

秘匿モード
認証付き秘匿モード（注14）メッセージ認証コード

XTS（注17）
該当なし
PC-MAC-AES

認証暗号
エンティティ認証

ChaCha20-Poly1305
ISO/IEC 9798-4

暗号利用モード（注５）

KEM (Key Encapsulating Mechanism) – DEM (Data Encapsulating Mechanism) 構成
における利用を前提とする。

（注６）

CRYPTREC暗号リストにおいて、64ビットブロック暗号により、同一の鍵を用いて暗号化する場合、220ブロックまで、同一の鍵を用いてCMACでメッセージ認証コードを生成する場合、221ブロックまでとする。

（注７）

平文サイズは64ビットの倍数に限る。

（注12） ハッシュ長は256ビット以上とすること。
（注14） CRYPTREC暗号リスト掲載のブロック暗号を、認証付き秘匿モードと組み合わせて、「認証暗号」として使うことができる。
（注17） ブロック暗号には、CRYPTREC暗号リスト掲載128ビットブロック暗号を使う。利用用
途はストレージデバイスの暗号化に限り、実装方法はNIST SP800-38Eに従うこと。

3

暗号利用モード、メッセージ認証コード、エンティティ認証は、他の技術分類の暗号技術と組み合わせて利用することとされているが、その場合、CRYPTREC暗号リストに掲載されたいずれかの暗号技術と組み合わせること。
6
CRYPTREC, 暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準, https://www.cryptrec.go.jp/list.html

3

運用監視暗号リスト
実際に解読されるリスクが高まるなど、推奨すべき状態ではなくなったと
CRYPTRECにより確認された暗号技術 4のうち、互換性維持のために継続利用を容認するもののリスト。互換性維持 7以外の目的での利用は推奨しない。なお、本リストに記載されている暗号技術を利用する際は、「暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準」 8の規定に合致する鍵長を用いることが求められることに留意
すること。
技術分類
公開鍵暗号

共通鍵暗号

暗号技術

署名
守秘

該当なし
RSAES-PKCS1-v1_5（注８）（注９）

鍵共有
64ビットブロック暗号（注15）
128ビットブロック暗号
ストリーム暗号

該当なし
3-key Triple DESRIPEMD-160
SHA-1（注８）
該当なし

ハッシュ関数
暗号利用モード

該当なし
該当なし

秘匿モード

認証付き秘匿モード（注16）メッセージ認証コード
認証暗号
エンティティ認証

該当なし
CBC-MAC（注11）
該当なし
該当なし

（注８）

「政府機関の情報システムにおいて使用されている暗号アルゴリズムSHA-1及び
RSA1024に係る移行指針」（平成20年４月 情報セキュリティ政策会議決定、平成24年 10 月 情 報 セ キ ュ リ テ ィ 対 策 推 進 会 議 改 定 ） を 踏 ま え て 利 用 す る こ と 。
https://www.nisc.go.jp/active/general/pdf/angou_ikoushishin.pdf（平成25年３月１日現在）（注９）

TLS 1.0, 1.1, 1.2で利用実績があることから当面の利用を認める。

（注11） 安全性の観点から、メッセージ長を固定して利用すべきである。
（注15） CRYPTREC暗号リストにおいて、64ビットブロック暗号により、同一の鍵を用いて暗号化する場合、220ブロックまで、同一の鍵を用いてCMACでメッセージ認証コードを生成する場合、221ブロックまでとする。
（注16） CRYPTREC暗号リスト掲載のブロック暗号を、認証付き秘匿モードと組み合わせて、「認証暗号」として使うことができる。

4

暗号利用モード、メッセージ認証コード、エンティティ認証は、他の技術分類の暗号技術と組み合わせて利用することとされているが、その場合、CRYPTREC暗号リストに掲載されたいずれかの暗号技術と組み合わせること。
7
既に稼働中のシステムやアプリケーション等との間での相互運用を継続すること
8
CRYPTREC, 暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準, https://www.cryptrec.go.jp/list.html

4変更履歴情報
変更日付
変更箇所
平成27年 （注10）３月27日

変更前の記述変更後の記述128-bit RC4は、SSL（TLS1.0 互換性維持のために継続利用を以上）に限定して利用するこ これまで容認してきたが、今後はと。
極力利用すべきでない。SSL/TLS
での利用を含め、電子政府推奨暗号リストに記載された暗号技術への移行を速やかに検討すること。
SHA-512/256
平成28年 推奨候補暗号リスト 該当なし
SHA3-256
３月29日 (技術分類：ハッシュ
SHA3-384
関数)
SHA3-512SHAKE256（注12）（注12）[新規追加]
ハッシュ長は256ビット以上とすること。
平成29年 推奨候補暗号リスト SHA-512/256
SHA-512/256
３月30日 （技術分類：ハッシュ SHA3-256
SHA3-256
SHA3-384
関数）
SHA3-384
SHA3-512
SHA3-512SHAKE256（注12）
SHAKE128（注12）
SHAKE256（注12）
平成30年 （注２）より長いブロック長の暗号が CRYPTREC暗号リスト におい て、
３月29日 （注６）
利用できるのであれば、128 64ビットブロック暗号により、同一ビットブロック暗号を選択する の鍵を用いて暗号化する場合、220
ことが望ましい。
ブロックまで、同一の鍵を用いてCMACでメッセージ認証コードを生（注15）[新規追加]
成する場合、221 ブロックまでとする。
（注３）
電子政府推奨暗号リ 3-key Triple DES
該当なし
スト（技術分類：共通
鍵暗号）
（注３）
3-key Triple DESは、以下の [削除]条件を考慮し、当面の利用を認める。
１） NIST SP 800-67として規定されていること。
２） デファクトスタンダードとしての位置を保っていること。
運用監視暗号リスト 該当なし
3-Key Triple DES（注１５）（ 技 術 分 類： 共 通 鍵
暗号）
電子政府推奨暗号リ [技術分類の新設]
技術分類：認証暗号
スト
暗号技術：該当なし
推奨候補暗号リスト
技術分類：認証暗号
暗号技術：ChaCha20-Poly1305
運用監視暗号リスト
技術分類：認証暗号
暗号技術：該当なし

5

（注13）（注14）（注16）[新規追加]CRYPTREC暗号リスト掲載のブロ
ック暗号を、認証付き秘匿モードと組み合わせて、「認証暗号」として使うことができる。
暗号技術

電子政府推奨暗号リ 名称
スト（見出し）推奨候補暗号リスト（見出し）
運用監視暗号リスト（見出し）
令 和 ２ 年 推奨候補暗号リスト 該当なし
12月21日 （ 技 術 分 類： 暗 号 利
用モ ード 秘匿モ ード）（注17）[新規追加]

XTS（注17）

ブロック暗号には、CRYPTREC暗号リスト掲載128ビットブロック暗号を使う。利用用途はストレージデバ
イスの暗号化に限り、実装方法はNIST SP800-38Eに従うこと。
該当なし

令 和 ３ 年 運用監視暗号リスト 128-bit RC4（注10）
４月１日 （ 技 術 分 類： 共 通 鍵
暗号）
（注10）
互換性維持のために継続利 [削除]
用をこれまで 容認して きたが、今後は極力利用すべきで な い 。 TLS で の 利 用 を 含
め、電子政府推奨暗号リストに記載された暗号技術への移行を速やかに検討すること。
令和４年 文書クレジット
総務省・経済産業省
デジタル庁・総務省・経済産業省
３月３０日 推奨候補暗号リスト 該当なし
EdDSA
（ 技 術 分 類： 公 開 鍵
暗号 署名）
電子政府推奨暗号リ 暗号技術検討会及び関連委 暗号技術検討会及び関連委員会
スト（本文）
員会（以下、「CRYPTREC」と （以下、「CRYPTREC」という。）にいう。）により安全性及び実装 より安全性及び実装性能が確認さ性能が確認された暗号技術 れた暗号技術について、市場におについて、市場における利用 ける利用実績が十分であるか今
実績が十分であるか今後の 後の普及が見込まれると判断さ
普及が見込まれると判断さ れ、当該技術の利用を推奨するもれ、当該技術の利用を推奨 ののリスト。なお、利用する鍵長について、「暗号強度要件（アルゴリするもののリスト。
ズム及び鍵長選択）に関する設定基準」の規定に合致しない鍵長を用いた場合には、電子政府推奨暗号リストの暗号技術を利用しているとは見なされないことに留意すること。

6

電子政府推奨暗号リ 「暗号強度要件（アルゴリズ 「暗号強度要件（アルゴリズム及びスト（本文）
ム及び鍵長選択）に関する設 鍵長選択）に関する設定基準」5定基準」
5CRYPTREC, 暗号強度要件（アルゴリズム及電子政府推奨暗号リ 該当なし
び鍵長選択）に関する設定基準,
スト（脚注）
https://www.cryptrec.go.jp/list.html
推奨候補暗号リスト CRYPTREC に よ り 安 全 性 及 CRYPTRECにより安全性及び実装（本文）
び実装性能が確認され、今 性能が確認され、今後、電子政府
後、電子政府推奨暗号リスト 推奨暗号リストに掲載される可能に掲載される可能性のある 性のある暗号技術のリスト。なお、
本リストに記載されている暗号技
暗号技術のリスト。
術を利用する際は、「暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準」の規定に合致する鍵長を用いることが求められることに留意すること。
推奨候補暗号リスト 「暗号強度要件（アルゴリズ 「暗号強度要件（アルゴリズム及び（本文）
ム及び鍵長選択）に関する設 鍵長選択）に関する設定基準」6定基準」
6CRYPTREC, 暗号強度要件（アルゴリズム及推奨候補暗号リスト 該当なし
び鍵長選択）に関する設定基準,（脚注）
https://www.cryptrec.go.jp/list.html
運用監視暗号リスト 実際に解読されるリスクが高 実際に解読されるリスクが高まる（本文）
まるなど、推奨すべき状態で など、推奨すべき状態ではなくなっはなくなったとCRYPTRECに たとCRYPTRECにより確認されたより確認された暗号技術のう 暗号技術のうち、互換性維持のた
ち、互換性維持のた めに継 めに継続利用を容認するもののリ
続利用を容認するもののリス スト。互換性維持以外の目的でのト。互換性維持以外の目的で 利用は推奨しない。なお、本リストに記載されている暗号技術を利用の利用は推奨しない。
する際は、「暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準」の規定に合致する鍵長を用いることが求められることに留意すること。
運用監視暗号リスト 互換性維持
互換性維持7（本文）
7
既に稼働中のシステムやアプリケーション等
運用監視暗号リスト 該当なしとの間での相互運用を継続すること（脚注）
運用監視暗号リスト 「暗号強度要件（アルゴリズ 「暗号強度要件（アルゴリズム及び（本文）
ム及び鍵長選択）に関する設 鍵長選択）に関する設定基準」8定基準」
8CRYPTREC, 暗号強度要件（アルゴリズム及運用監視暗号リスト 該当なし
び 鍵 長選 択） に 関す る 設 定基 準,（脚注）
https://www.cryptrec.go.jp/list.html
令和●年 推奨候補暗号リスト SC2000●月●日 （ 技 術 分 類： 共 通 鍵
暗号 128ビットブロッ
ク暗号）

[削除]

7

資料４－３
CRYPTREC LS-0001-2022

事前に資料２の内容が承認されたと仮定して作成

電子政府における調達のために参照すべき暗号のリスト（CRYPTREC暗号リスト）（案）令和●年●月●日
デジタル庁・総務省・経済産業省
電子政府推奨暗号リスト
暗号技術検討会 1 及び関連委員会（以下、「CRYPTREC」という。）により安全性及び実装性能が確認された暗号技術 2 について、市場における利用実績が十分であるか今後の普及が見込まれると判断され、当該技術の利用を推奨するもののリスト。
なお、利用する鍵長について、「暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準」 5の規定に合致しない鍵長を用いた場合には、電子政府推奨暗号リストの暗号技術を利用しているとは見なされないことに留意すること。
技術分類

暗号技術
DSA
ECDSA
EdDSA
RSA-PSS（注１）
RSASSA-PKCS1-v1_5（注１）
RSA-OAEP（注１）

署名
公開鍵暗号
守秘
鍵共有
64ビットブロック暗号（注２）
共通鍵暗号

DH
ECDH
該当なし
AES
Camellia
KCipher-2
SHA-256

128ビットブロック暗号
ストリーム暗号

SHA-384
SHA-512
SHA-512/256
ハッシュ関数

SHA3-256
SHA3-384
SHA3-512SHAKE128（注12）

暗号利用モードSHAKE256（注12）
CBC

秘匿モード

CFB

1

デジタル庁統括官、総務省サイバーセキュリティ統括官及び経済産業省商務情報政策局長が有識者の参集を求め、暗号技術の普及による情報セキュリティ対策の推進を図る観点から、専門家による意見等を聴取することにより、デジタル庁、総務省及び経済産業省における施策の検討に資することを目的として開催。
2
暗号利用モード、メッセージ認証コード、エンティティ認証は、他の技術分類の暗号技術と組み合わせて利用することとされているが、その場合、CRYPTREC暗号リストに掲載されたいずれかの暗号技術と組み合わせること。
5
CRYPTREC, 暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準, https://www.cryptrec.go.jp/list.html

1

CTR
OFB
XTS（注17）
認証付き秘匿モード（注13）メッセージ認証コード
認証暗号

CCM
GCM（注４）CMAC
HMAC
ChaCha20-Poly1305
ISO/IEC 9798-2
ISO/IEC 9798-3
ISO/IEC 9798-4

エンティティ認証（注１）「政府機関の情報システムにおいて使用されている暗号アルゴリズムSHA-1及び
RSA1024に係る移行指針」（平成20年４月情報セキュリティ政策会議決定、平成24年 10 月 情 報 セ キ ュ リ テ ィ 対 策 推 進 会 議 改 定 ） を 踏 ま え て 利 用 す る こ と 。
https://www.nisc.go.jp/pdf/policy/general/angou_ikoushishin.pdf（平成25年３月１日現在）（注２）

CRYPTREC暗号リストにおいて、64ビットブロック暗号により、同一の鍵を用いて暗号化する場合、220ブロックまで、同一の鍵を用いてCMACでメッセージ認証コードを生成する場合、221ブロックまでとする。

（注４）

初期化ベクトル長は96ビットを推奨する。

（注12） ハッシュ長は256ビット以上とすること。
（注13） CRYPTREC暗号リスト掲載のブロック暗号を、認証付き秘匿モードと組み合わせて、「認証暗号」として使うことができる。
（注17） ブロック暗号には、CRYPTREC暗号リスト掲載128ビットブロック暗号を使う。利用用
途はストレージデバイスの暗号化に限り、実装方法はNIST SP800-38Eに従うこと。

2

推奨候補暗号リスト
CRYPTRECにより安全性及び実装性能が確認され、今後、電子政府推奨暗号リス
トに掲載される可能性のある暗号技術 3 のリスト。なお、本リストに記載されている暗号技術を利用する際は、「暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準」 6の規定に合致する鍵長を用いることが求められることに留意すること。
技術分類

暗号技術

署名
守秘

該当なし
該当なし

鍵共有
64ビットブロック暗号（注６）PSEC-KEM（注５）
CIPHERUNICORN-E
Hierocrypt-L1
MISTY1CIPHERUNICORN-A

128ビットブロック暗号

CLEFIA

ストリーム暗号
ハッシュ関数

Hierocrypt-3
Enocoro-128v2
MUGI
MULTI-S01（注７）
該当なし

秘匿モード
認証付き秘匿モード（注14）メッセージ認証コード
認証暗号
エンティティ認証該当なし
該当なし
PC-MAC-AES
該当なし
該当なし

公開鍵暗号

共通鍵暗号

暗号利用モード（注５）

KEM (Key Encapsulating Mechanism) – DEM (Data Encapsulating Mechanism) 構成
における利用を前提とする。

（注６）

CRYPTREC暗号リストにおいて、64ビットブロック暗号により、同一の鍵を用いて暗号化する場合、220ブロックまで、同一の鍵を用いてCMACでメッセージ認証コードを生成する場合、221ブロックまでとする。

（注７）

平文サイズは64ビットの倍数に限る。

（注14） CRYPTREC暗号リスト掲載のブロック暗号を、認証付き秘匿モードと組み合わせて、「認証暗号」として使うことができる。

3

暗号利用モード、メッセージ認証コード、エンティティ認証は、他の技術分類の暗号技術と組み合わせて利用することとされているが、その場合、CRYPTREC暗号リストに掲載されたいずれかの暗号技術と組み合わせること。
6
CRYPTREC, 暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準, https://www.cryptrec.go.jp/list.html

3

運用監視暗号リスト
実際に解読されるリスクが高まるなど、推奨すべき状態ではなくなったと
CRYPTRECにより確認された暗号技術 4のうち、互換性維持のために継続利用を容認するもののリスト。互換性維持 7以外の目的での利用は推奨しない。なお、本リストに記載されている暗号技術を利用する際は、「暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準」 8の規定に合致する鍵長を用いることが求められることに留意
すること。
技術分類
公開鍵暗号

共通鍵暗号

暗号技術

署名
守秘

該当なし
RSAES-PKCS1-v1_5（注８）（注９）

鍵共有
64ビットブロック暗号（注15）
128ビットブロック暗号
ストリーム暗号

該当なし
3-key Triple DESRIPEMD-160
SHA-1（注８）
該当なし

ハッシュ関数
暗号利用モード

該当なし
該当なし

秘匿モード

認証付き秘匿モード（注16）メッセージ認証コード
認証暗号
エンティティ認証

該当なし
CBC-MAC（注11）
該当なし
該当なし

（注８）

「政府機関の情報システムにおいて使用されている暗号アルゴリズムSHA-1及び
RSA1024に係る移行指針」（平成20年４月 情報セキュリティ政策会議決定、平成24年 10 月 情 報 セ キ ュ リ テ ィ 対 策 推 進 会 議 改 定 ） を 踏 ま え て 利 用 す る こ と 。
https://www.nisc.go.jp/pdf/policy/general/angou_ikoushishin.pdf（平成25年３月１日現在）（注９）

TLS 1.0, 1.1, 1.2で利用実績があることから当面の利用を認める。

（注11） 安全性の観点から、メッセージ長を固定して利用すべきである。
（注15） CRYPTREC暗号リストにおいて、64ビットブロック暗号により、同一の鍵を用いて暗号化する場合、220ブロックまで、同一の鍵を用いてCMACでメッセージ認証コードを生成する場合、221ブロックまでとする。
（注16） CRYPTREC暗号リスト掲載のブロック暗号を、認証付き秘匿モードと組み合わせて、「認証暗号」として使うことができる。

4

暗号利用モード、メッセージ認証コード、エンティティ認証は、他の技術分類の暗号技術と組み合わせて利用することとされているが、その場合、CRYPTREC暗号リストに掲載されたいずれかの暗号技術と組み合わせること。
7
既に稼働中のシステムやアプリケーション等との間での相互運用を継続すること
8
CRYPTREC, 暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準, https://www.cryptrec.go.jp/list.html

4意見募集の実施方法及びその後の対応について（案）資料５

電子政府における調達のために参照すべき暗号のリスト（CRYPTREC暗号リスト）の改定に係る意見募集の実施及びその後の対応を以下のとおり進めることについて、御審議いただきたい。
1. 意見募集の実施方法【意見募集対象】
資料４－３

電子政府における調達のために参照すべき暗号のリスト（CRYPTREC暗号リスト）（改定案）【意見募集期間】
令 和 5 年 3 月 9 日 （ 木 ） か ら 同 年３月23日（木）までの15日 間【意見募集方法】
電 子 政 府 の 総 合 窓 口 (e-Gov)、デジタル庁、総務省及び経済産業省のHPに掲載【意見提出方法】
e-Gov、 郵 送 、 電 子 メ ー ル

２. 意見募集実施後の対応提出された意見を踏まえ、暗号技術検討会で審議の上、CRYPTREC暗号リストの改定に関して決定・公表する。

参考資料１

電子政府推奨暗号リスト掲載への推薦候補案について
暗号技術活用委員会では、暗号アルゴリズム利用実績調査の結果（参考資料２）及び 2021 年度に承認された別紙記載の利用実績に基づく選定基準（選定ルール）に基づき、現在の推奨候補暗号リストに掲
載のアルゴリズムのうち、電子政府推奨暗号リスト掲載への推薦候補案を以下の通り決定したので、報告する。
(1) エンティティ認証、ハッシュ関数、署名を除いた技術分類について：
技術分類

推薦候補

推薦しない候補理由

公開鍵 鍵共有

該当なし

PSEC-KEM

 他の鍵共有と比較して優位な利

暗号用実績があるとは認められない

共通鍵 64 ビットブロ 該当なし

CIPHERUNICORN-E

暗号

Hierocrypt-L1

較して優位な利用実績があると

MISTY1は認められないック暗号

 他の 64 ビットブロック暗号と比128 ビットブ 該当なし

CIPHERUNICORN-A

ロック暗号

CLEFIA

比較して優位な利用実績がある

Hierocrypt-3とは認められない 他の 128 ビットブロック暗号とSC2000
ストリーム暗 該当なし

Enocoro-128v2

号

MUGI

優位な利用実績があるとは認め

MULTI-S01

られない

認証暗号

ChaCha20-Poly1305 該当なし

 他のストリーム暗号と比較して

 考慮項目①②④について、利用実績があると認められる

暗号利 秘匿モード

XTS

該当なし

 考慮項目①②④について、他の秘用モー匿モードと比較して利用実績がドあると認められる

メッセージ認証コード

該当なし

PC-MAC-AES

 他のメッセージ認証コードと比
較して優位な利用実績があるとは認められない(2) エンティティ認証について：
技術分類

推薦候補

推薦しない候補

理由

エンティティ認証

ISO/IEC 9798-4

該当なし

 考慮項目①②において、他のエン
ティティ認証と比較して利用実績があると認められる

1

(3) ハッシュ関数について：
技術分類

推薦候補

推薦しない候補

理由

ハッシュ関数

SHA-512/256

該当なし

 考慮項目④において、他のハッシ

SHA3-256

ュ関数と比較して利用実績があSHA3-384

ると認められる

SHA3-512SHAKE128SHAKE256(4) EdDSA について：
技術分類

推薦候補

推薦しない候補理由

公開鍵 署名

EdDSA

該当なし

 考慮項目④において、他の署名と暗号比較して利用実績があると認め
られる

以上

2

【参考】
技術分類

公開鍵暗号

署名

電子政府推奨暗号

推奨候補暗号

運用監視暗号

DSA

EdDSA

該当なし

RSA-OAEP

該当なし

RSAES-PKCS1-v1_5

DH

PSEC-KEM

該当なし

CIPHERUNICORN-E

3-key Triple DES

ECDSA
RSA-PSSRSASSA-PKCS1-v1_5

守秘
鍵共有

ECDH
該当なし

Hierocrypt-L1

64 ビットブロック暗号

MISTY1
共通鍵暗号

128 ビットブロック暗号

AES

CIPHERUNICORN-A

Camellia

CLEFIA

該当なし

Hierocrypt-3
SC2000
KCipher-2

Enocoro-128v2

該当なし

MUGI

ストリーム暗号MULTI-S01

ハッシュ関数

SHA-256

SHA-512/256

RIPEMD-160

SHA-384

SHA3-256

SHA-1

SHA-512

SHA3-384
SHA3-512SHAKE128SHAKE256

暗号利用モード

CBC
秘匿モード

XTS

該当なし

該当なし

該当なし

PC-MAC-AES

CBC-MAC

該当なし

ChaCha20-Poly1305

該当なし

ISO/IEC 9798-2

ISO/IEC 9798-4

該当なし

CFB
CTR
OFB

認証付き秘匿モード
メッセージ認証コード
認証暗号
エンティティ認証

CCM
GCM
CMAC
HMAC

ISO/IEC 9798-3

3

【別紙 1】＜選定基準＞
本選定基準は、暗号技術評価委員会で安全性及び実装性の評価を実施し、その評価結果により暗号技術検討会が推奨候補暗号リストに含めると決定した暗号技術に対して、電子政府推奨暗号リストへの昇格を決めるための基準である。昇格検討対象の暗号技術は、以下の考慮項目での目安に基づき、暗号技術活用委員会にて検討、選定し、暗号技術検討会に推薦する。
推薦された暗号技術について、暗号技術検討会では、その根拠となった利用実態を再度確認・審議を行い、電子政府推奨暗号リストへの昇格に問題がないと判断した場合に電子政府推奨暗号リストに選定する。
考慮項目

選定目安

採用実績 以下のいずれかを満たす場合、昇格の検討対象に含める。なお、採用実績は、
 5 年ごとに実施予定の大規模アンケート調査

による「利用実績調査」
 必要に応じて、事務局が（大規模アンケート調

査によらずに）情報収集する「利用実態確認」
により確認するものとする。
① 利用実績調査の結果、電子政府推奨暗号リス 電子政府推奨暗号リスト掲載の（同一カテトに掲載されている（同一カテゴリの）暗号 ゴリの）暗号技術の採用実績と同等以上の技術の採用実績と遜色がないことが確認され 採用実績がある推奨候補暗号リスト掲載の暗号技術を昇格検討対象とする。

た場合② 利用実績調査又は利用実態確認の結果、電子 必要に応じて、利用実績調査に代わって、各政府システムや重要インフラ等、日本の基幹 府省庁等への照会を実施し、照会結果（クロシステムにおいてすでに利用されていること ーズドな利用を含め）を基に昇格検討対象を選定する。

が確認された場合

利用実績調査又は利用実態確認の結果、③～⑤の 「複数」
「利用者が多い（主要な）」というキーワードの両方を十分に満たし、明らかないずれかが確認された場合：③ 利用者が多い主要な汎用製品群の複数に搭 採用促進が確認された場合には、必要に応載されるなど、明らかに採用が進展している じて、昇格検討対象とする。
※「複数」の意味は、必要条件として「2 個と判断された場合④ 利用者が多い主要なオープンソースソフト 以上が必要」ということであって、「2 個以ウェアの複数に搭載されるなど、明らかに採 上あればよい」という十分条件としての意用が進展していると判断された場合味ではないことに留意⑤ 利用者が多い主要なサービスやプロトコルの複数で利用されるなど、明らかに採用が進展していると判断された場合
標準化実 以下を満たす場合、昇格の検討対象に含める。
績⑥ 利用実績調査の結果、電子政府推奨暗号リス 電子政府推奨暗号リスト掲載の（同一カテトに掲載されている（同一カテゴリの）暗号 ゴリの）暗号技術の採用実績と同等以上の

4

技術の採用実績と遜色がないことが確認され 採用実績がある推奨候補暗号リスト掲載の暗号技術は昇格検討対象とする。

た場合5参考資料２

暗号アルゴリズム利用実績調査報告1

委託調査概要
 委託調査概要
 株式会社野村総合研究所に委託して実施
 調査対象アルゴリズムは以下の通り※※署名 「EdDSA」は、調査（C）の規格調査、及び（D）（E）について事務局で独自に調査し、調査結果をP16-18に記載した。

2

委託調査概要
 調査内容調査対象
中間報告時(A) 応募暗号アルゴリズムの応募 応募暗号アルゴリズムの応者に対するアンケート調査
募者 ８社（16アルゴリズム）(B) 暗号アルゴリズムを搭載している市販製品の販売会社への調査

合計1,500社以上• 14業界団体 2,535社• 個別コンタクト 102社
• 調査パネル 23,747名

最終実績• 全8社から回答受領
アルゴリズム実績提供：11アルゴリズム→ 調査(C)(D)(E)の情報として活用
製品実績提供：4アルゴリズム→ 調査(B)の情報として活用• アンケート回収数：211社301製品••••

業界団体：2,535社 → 65社114製品
個別：108社 → 28社37製品(A)調査：4社4製品
調査パネル：23,747名 → 146製品⇓• 集計対象：101社209製品• アンケート有効回答：82社128製品（利用アルゴリズム
不明19製品を含む）• 公開情報調査（補充調査）：41社100製品(C) 日本の政府機関等に対する調査

法省令・ガイドライン・政府系 • アンケート集計数：
デジタル庁／IPA経由で提供された98シス
システム規格・重要インフラ
規格 最大20件
テム• 規格調査数：全30件
うち、暗号アルゴリズム記載ありは17件(D) 国際標準規格・民間規格等に 国際標準規格・民間規格等 • 規格調査数：IPAが指定した25件
対する調査
最大25件
（※別途追加分：146件）• OSS調査数：IPAが指定した30件(E) オープンソースソフトウェアで オープンソースソフトウェア（※EdDSAだけ独自追加実施）の利用実績調査
最大30件
3委託調査結果(B)
利用アルゴリズム不明
19製品を除外

 集計対象の選定
アンケート回収数：211社301製品••••

業界団体：2,535社 → 65社114製品
個別：108社 → 28社37製品(A)調査：4社4製品
調査パネル：23,747名 → 146製品

アンケート有効回答：82社128製品••••

業界団体：65社114製品 → 65社99製品
個別：28社37製品 → 10社17製品(A)調査：4社4製品 → 3社3製品
調査パネル：146製品 → 9社9製品

集計対象：
101社
209製品

公開情報調査：41社100製品【除外理由】
 有効回答は1社につき5製品まで。6製品以上は、IPAと相談のうえ5製品に絞り込み
 個別企業調査の回答には、アンケート調査への協力を辞退する旨の回答が含まれていた 応募者(A)調査や調査パネルの回答には、企業名や製品・システム名が不明瞭なものが多く含まれており、ウェブ調査にて特定できないものについては除外

調査パネルの回答（製品数ベース）

個別企業調査の回答（会社数ベース）
4委託調査結果(B) 集計対象の製品カテゴリ分布（アンケート調査）（公開情報調査）

5

委託調査結果(C) 規格調査対象
1 電子署名及び認証業務に関する法律に基づく特定認証業務の認定に係る指針 [2020年版]
2 公的個人認証サービス 利用者証明用認証局 運用規程 第2.1版（2021年9月1日）
3 商業登記認証局「電子証明書の方式等に関する件（告示）」（2019年11月29日変更）
4 政府認証基盤（GPKI） 政府認証基盤相互運用性仕様書 2021年版
5 住民基本台帳法（昭和42年法律第81号）住民基本台帳カード Version 2 組込みソフトウェア プロテクションプ

ロファイル [2011年1月21日]
6 標準テレビジョン放送等のうちデジタル放送に関する送信の標準方式第八条第一号及び第二号の規定に基づくスクランブルの方式 平成26年7月3日 総務省告示第235号（平成27年3月20日施行）
7 政府認証基盤（GPKI）ブリッジ認証局（BCA）との相互認証業務に関するCP/CPS（Ver. 5.0）[令和元年11月
29日]
8 LGPKI組織認証局R2 CPCPS - 地方公共団体組織認証基盤（LGPKI） [2020]
9 LGPKI技術仕様書 [20190520]
10 認証業務及びこれに附帯する業務の実施に関する技術的基準 [令和三年二月十五日]
11 商業登記認証局「電子証明書の方式等に関する件（告示） [2019.11.29]
付録1 電磁的記録への記録方式（ASN.1構造とオブジェクト識別子）
12 オンライン請求ネットワーク関連システム 共通認証局運用規程 [令和2年9月]
13 総務省告示第七百六号 電子署名に係る地方公共団体の認証業務 [平成十五年十二月三日]
14 医療情報システムの安全管理に関するガイドライン 第5.2版（令和4年3月）
15 クレジットカード・セキュリティガイドライン 3.0 版（2022年3月）
16 【鉄道事業者用】情報セキュリティ対策チェックリスト（令和3年4月第2版）
17 【空港・空港ビル事業者用】情報セキュリティ対策チェックリスト（令和3年4月）
6委託調査結果(D) 規格調査対象
1 RFC 6043
2 RFC 6476
3 RFC 6637
4 RFC 6781
5 RFC 8645
6 RFC 8702
7 RFC 8708
8 RFC 8723
9 RFC 8725
10 RFC 8732
11 RFC 8778
12 RFC 8812

MIKEY-TICKET Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY)
Using Message Authentication Code (MAC) Encryption in the Cryptographic Message Syntax (CMS)
Elliptic Curve Cryptography (ECC) in OpenPGPDNSSEC Operational Practices, Version 2
Re-keying Mechanisms for Symmetric Keys
Use of the SHAKE One-Way Hash Functions in the Cryptographic Message Syntax (CMS)
Use of the HSS/LMS Hash-Based Signature Algorithm in the Cryptographic Message Syntax (CMS)
Double Encryption Procedures for the Secure Real-Time Transport Protocol (SRTP)
JSON Web Token Best Current Practices
Generic Security Service Application Program Interface (GSS-API) Key Exchange with SHA-2
Use of the HSS/LMS Hash-Based Signature Algorithm with CBOR Object Signing and Encryption (COSE)
CBOR Object Signing and Encryption (COSE) and JSON Object Signing and Encryption (JOSE) Registrations for Web
Authentication (WebAuthn) Algorithms

A Solution Framework for Private Media in Privacy-Enhanced RTP Conferencing (PERC)
13 RFC 8871
Network Time Security for the Network Time Protocol
14 RFC 8915
Use of the Walnut Digital Signature Algorithm with CBOR Object Signing and Encryption (COSE)
15 RFC 9021
Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA')
16 RFC 9048
An Automatic Certificate Management Environment (ACME) Profile for Generating Delegated Certificates
17 RFC 9115
Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification
18 RFC 9132
Nimble Out-of-Band Authentication for EAP (EAP-NOOB)
19 RFC 9140
Integrity Protection for the Network Service Header (NSH) and Encryption of Sensitive Context Headers
20 RFC 9145
IEEE Standard for Cryptographic Protection of Data on Block-Oriented Storage Devices
21 IEEE Std 1619-2018
IEEE Standard for Ethernet
22 IEEE Std 802.3-2018
23 IEEE Std 1609.2-2016 IEEE Standard for Wireless Access in Vehicular Environments—Security Services for Applications and Management Messages
IEEE Standard for Broadband over Power Line Networks: Medium Access Control and Physical Layer Specifications
24 IEEE Std 1901-2020
25 IEEE Std 802.15.6-2012 IEEE Standard for Local and metropolitan area networks - Part 15.6: Wireless Body Area Networks

7【参考】委託調査結果(D) 追加民間規格対象（2012調査：50, 2019調査：35, 2022独自調査：42）

TLS
(26)

IPsec
(32)

規格番号 規格名
RFC2246 The TLS Protocol Version 1.0
RFC2712 Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)
RFC3268 Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)
RFC4162 Addition of SEED Cipher Suites to Transport Layer Security (TLS)
RFC4346 The Transport Layer Security (TLS) Protocol Version 1.1
RFC4785 Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS)
RFC5246 The Transport Layer Security (TLS) Protocol Version 1.2
RFC5288 AES Galois Counter Mode (GCM) Cipher Suites for TLS
RFC5289 TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)
RFC5430 Suite B Profile for Transport Layer Security (TLS)
RFC5487 Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode
RFC5489 ECDHE_PSK Cipher Suites for Transport Layer Security (TLS)
RFC5932 Camellia Cipher Suites for TLS
RFC7627 Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension
RFC7905 ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS)
RFC7918 Transport Layer Security (TLS) False Start
RFC7919 Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)
RFC7924 Transport Layer Security (TLS) Cached Information Extension
RFC7925 Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things
RFC8422 Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier
RFC8442 ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for TLS 1.2 and DTLS 1.2
RFC8446 The Transport Layer Security (TLS) Protocol Version 1.3
RFC6209 Addition of the ARIA Cipher Suites to Transport Layer Security (TLS)
RFC6367 Addition of the Camellia Cipher Suites to Transport Layer Security (TLS)
RFC6655 AES-CCM Cipher Suites for Transport Layer Security (TLS)
RFC7251 AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS
RFC2403 The Use of HMAC-MD5-96 within ESP and AH
RFC2404 The Use of HMAC-SHA-1-96 within ESP and AH
RFC2405 The ESP DES-CBC Cipher Algorithm With Explicit IV
RFC2451 ESP CBC-Mode Cipher Algorithms
RFC2857 The Use of HMAC-RIPEMD-160-96 within ESP and AH
RFC3526 More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)
RFC3566 The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec

調査年
2012
2012
2012
2012
2012
2012
2012
2012
2012
2012
2012
2012
2012
2019
2019
2019
2019
2019
2019
2019
2019
2019
2022
2022
2022
2022
2012
2012
2012
2012
2012
2012
2012 8

【参考】委託調査結果(D)

IPsec
(32)

S/MIME(15)

規格番号 規格名
調査年
2012
RFC3602 The AES-CBC Cipher Algorithm and Its Use with Ipsec
Using
Advanced
Encryption
Standard(AES)
Counter
Mode
With
IPsec
Encapsulating
Security
Payload(ESP)
RFC3686
2012
RFC4106 The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)
2012
The
SEED
CipherAlgorithm
and
Its
Use
with
IPsecz
RFC4196
2012
RFC4301 Security Architecture for the Internet Protocol
2012
Cryptographic
Algorithm
Implementation
RequirementsforEncapsulating
Security
Payload(ESP)
andAuthentication
Header(AH)
RFC43052012
RFC4308 Internet Security Association and Key Management Protocol (ISAKMP)
2012
Using
Advanced
Encryption
Standard
(AES)
CCM
Mode
with
IPsec
Encapsulating
Security
Payload(ESP)
RFC43092012
RFC4312 The Camellia Cipher Algorithm and Its Use With Ipsec
2012
RFC4494 The AES-CMAC-96 Algorithm and Its Use with IPsec
2012
RFC4543 The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH
2012
The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (AES-CMAC-PRF-128)
2012
RFC4615 Algorithm for the Internet Key Exchange Protocol (IKE)2012
RFC4868 Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with Ipsec
RFC4869 Suite B Cryptographic Suites for IPsec
2012
Internet
Key
Exchange
ProtocolVersion2(IKEv2)
RFC7296
2019
RFC7427 Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)
2019
ChaCha20,
Poly1305,
and
Their
Use
in
the
Internet
Key
Exchange
Protocol
(IKE)
and
Ipsec
RFC7634
2019
Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication
2019
RFC8221 Header (AH)2019
RFC8229 TCP Encapsulation of IKE and IPsec Packets
RFC8247 Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2)
2019
RFC8420 Using the Edwards-Curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange Protocol Version 2 (IKEv2)
2019
RFC3830 MIKEY: Multimedia Internet KEYing
2022
Additional Cryptographic Algorithms for Use with GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
2022
RFC4357 Algorithms
2022
RFC5528 Camellia Counter Mode and Camellia Counter with CBC-MAC Mode Algorithms
IANA
Registry
Updatefor
Supportofthe
SEED
CipherAlgorithm
inMultimedia
Internet
KEYing(MIKEY)
RFC5748
2022
RFC3565 Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)2012
RFC3657 Use of the Camellia Encryption Algorithm in Cryptographic Message Syntax (CMS)2012
RFC3853 S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)2012
RFC4056 Use of the RSASSA-PSS Signature Algorithm In Cryptographic Message Syntax (CMS)2012
RFC5083 Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type2012
RFC5652 Cryptographic Message Syntax (CMS)2012 9

【参考】委託調査結果(D)
規格番号 規格名
調査年
2012
RFC5753 Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)2012
RFC5754 Using SHA2 Algorithms with Cryptographic Message Syntax
2019
RFC8103 Using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS)
Use
of
the
Elliptic
Curve
Diffie-Hellman
Key
Agreement
Algorithm
withX25519
and
X448
in
the
Cryptographic
Message
Syntax(CMS)
2019
RFC8418
S/MIME2019
RFC8419 Use of Edwards-Curve Digital Signature Algorithm (EdDSA) Signatures in the Cryptographic Message Syntax (CMS)(15)
Secure/Multipurpose
Internet
Mail
Extensions(S/MIME)
Version
4.0
Certificate
Handling
2019
RFC8550
2019
RFC8551 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification
Use
of
the
RSA-KEMKey
Transport
Algorithm
inthe
Cryptographic
Message
Syntax(CMS)
2022
RFC5990
2022
RFC9044 Using the AES-GMAC Algorithm with the Cryptographic Message Syntax (CMS)MIME
Security
with
OpenPGP2012
RFC3156
OpenPGP (2) RFC4880 OpenPGP Message Format
2012
Resource
Records
forthe
DNS
Security
Extensions
2012
RFC4034
2012
RFC4509 Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
Use
of
SHA-2
Algorithms
with
RSA
in
DNSKEYandRRSIG
Resource
Recordsfor
DNSSEC2012
RFC57022019
DNSSec RFC8080 Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC
Using
DNS
to
Securely
PublishSecure
Shell
(SSH)
Key
Fingerprints(8)2022
RFC4255
RFC6594 Use of the SHA-256 Algorithm with RSA, Digital Signature Algorithm (DSA), and Elliptic Curve DSA (ECDSA) in SSHFP Resource Records 2022
2022
RFC6605 Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC
2022
RFC8976 Message Digest for DNS Zones
Advanced
Encryption
Standard(AES)
Encryption
forKerberos5
2012
RFC3962
2012
RFC4120 The Kerberos Network Authentication Service (V5)
Kerberos
AES
Encryption
with
HMAC-SHA2
for
Kerberos5
2019
RFC8009(5)
2019
RFC8636 Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Algorithm Agility
Camellia
Encryption
forKerberos
5
2022
RFC68032019
RFC8268 More Modular Exponentiation (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH)
SSH
Use
of
RSA
Keys
with
SHA-256
andSHA-512inthe
Secure
Shell(SSH)
Protocol2019
RFC8332(3)
2022
RFC4250 The Secure Shell (SSH) Protocol Assigned Numbers
X.509
Internet
PublicKey
Infrastructure
OnlineCertificate
StatusProtocol
OCSP
2019
RFC6960
2019
RFC8410 Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure
Algorithms
andIdentifiers
fortheInternet
X.509
PublicKey
Infrastructure
Certificate
andCertificate
Revocation
List
(CRL)
Profile2022
RFC3279
PKIX
Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate(6)
RFC4055 Revocation List (CRL) Profile
2022
RFC5758 Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA
2022
2022 10
RFC8692 Internet X.509 Public Key Infrastructure: Additional Algorithm Identifiers for RSASSA-PSS and ECDSA Using SHAKEs

【参考】委託調査結果(D)
規格番号
RFC3711
RFC3713
RFC4568
RFC5669
RFC5764
RFC5794
RFC5830
RFC6030
RFC6114
RFC6188
RFC7008
RFC7714
RFC7801
RFC8017
RFC8032
RFC8230
RFC8269
RFC8439
RFC8452
RFC9231IEEE 802.11i-2004
IEEE Std 802.1AE
IEEE Std 802.1Q
IEEE Std 802.1Xbx
IEEE Std 802.11
IEEE Std 802.15.4
IEEE Std 802.16
IEEE Std 802.21
FIDO [2017]
TCG [2018]

規格名
The Secure Real-time Transport Protocol (SRTP)
A Description of the Camellia Encryption Algorithm
Session Description Protocol (SDP) Security Descriptions for Media Streams
The SEED Cipher Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP)
Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)
A Description of the ARIA Encryption Algorithm
GOST 28147-89: Encryption, Decryption, and Message Authentication Code (MAC) Algorithms
Portable Symmetric Key Container (PSKC)
The 128-Bit Blockcipher CLEFIAThe Use of AES-192 and AES-256 in Secure RTPA Description of the KCipher-2 Encryption Algorithm
AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP)
GOST R 34.12-2015: Block Cipher "Kuznyechik"
PKCS #1: RSA Cryptography Specifications Version 2.2
Edwards-Curve Digital Signature Algorithm (EdDSA)
Using RSA Algorithms with CBOR Object Signing and Encryption (COSE) Messages
The ARIA Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP)
ChaCha20 and Poly1305 for IETF Protocols
AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption
Additional XML Security Uniform Resource Identifiers (URIs)
IEEE Standard for information technology-Telecommunications and information exchange between systems-Local and metropolitan area
networks-Specific requirements-Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications:
Amendment 6: Medium Access Control (MAC) Security Enhancements
IEEE Standard for Local and metropolitan area networks-Media Access Control (MAC) Security
IEEE Standard for Local and Metropolitan Area Network--Bridges and Bridged Networks - Redline
IEEE Standard for Local and metropolitan area networks -- Port-Based Network Access Control Amendment 1: MAC Security Key
Agreement Protocol (MKA) Extensions
IEEE Standard for Information technology—Telecommunications and information exchange between systems Local and metropolitan area
networks—Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications
IEEE Standard for Low-Rate Wireless Networks
IEEE Standard for Air Interface for Broadband Wireless Access Systems
IEEE Standard for Local and metropolitan area networks--Part 21: Media Independent Services Framework
https://fidoalliance.org/specs/fido-security-requirements-v1.0-fd-20170524/fido-authenticator-allowed-cryptography-list_20170524.html
https://trustedcomputinggroup.org/wp-content/uploads/TCG-_Algorithm_Registry_Rev_1.27_FinalPublication.pdf

調査年
2022
2022
2022
2022
2022
2022
2022
2022
2022
2022
2022
2022
2022
2022
2022
2022
2022
2022
2022
2022
2012
2019
2019
2019
2019
2019
2019
2019
2022
2022 11

【参考】委託調査結果(D) 追加国際規格対象（2012調査：8, 2019調査：4, 2022独自調査：10）
規格番号

規格名

調査年

ISO/IEC

9797

1:2011

Message Authentication Codes (MACs) — Part 1: Mechanisms using a block cipher

2012

ISO/IEC9797

2:2021

Message authentication codes (MACs) — Part 2: Mechanisms using a dedicated hash-function

2022

ISO/IEC

9797

3:2011

Message Authentication Codes (MACs) — Part 3: Mechanisms using a universal hash-function

2022

ISO/IEC

10116

2017

Modes of operation for an n-bit block cipher

2019

ISO/IEC

10118

2:2010Hash-functions — Part 2: Hash-functions using an n-bit block cipher

2012

ISO/IEC

10118

3:2018Hash-functions — Part 3: Dedicated hash-functions

2019

ISO/IEC

14888

2:2008

Digital signatures with appendix — Part 2: Integer factorization based mechanisms

2012

ISO/IEC

14888

3:2018

Digital signatures with appendix — Part 3: Discrete logarithm based mechanisms

2019

ISO/IEC

18033

2:2006

Encryption algorithms — Part 2: Asymmetric ciphers

2012

ISO/IEC

18033

3:2010

Encryption algorithms — Part 3: Block ciphers

2012

ISO/IEC

18033

ISO/IEC

18033

AMD:2021 Encryption algorithms — Part 3: Block ciphers — AMENDMENT 1: SM4
Encryption algorithms — Part 4: Stream ciphers
4:2011

ISO/IEC

19772

2020

Authenticated encryption

2022

ISO/IEC

29192

2:2019Lightweight cryptography — Part 2: Block ciphers

2022

ISO/IEC

29192

3:2012

Lightweight cryptography — Part 3: Stream ciphers

2012

ITU-T

Y.270401/2010

Security mechanisms and procedures for NGN

2012

ITU-T

X.119704/2012

Guidelines on criteria for selecting cryptographic algorithms for IPTV service and content
protection

2022

ITU-T

X.1197

09/2019

Guidelines on criteria for selecting cryptographic algorithms for IPTV service and content
protection Amendment 1

2022

ITU-T

X.1811

04/2021

Security guidelines for applying quantum-safe algorithms in IMT-2020 systems

2022

ITU-T

X.1372

03/2020

Security guidelines for vehicle-to-everything (V2X) communication

2022

ITU-T

H235.601/2014

H.323 security: Encryption profile with native ITU-T H.235/H.245 key management

2019

ICAO

Doc9303-11 2021

Machine Readable Travel Documents Part 11: Security Mechanisms for MRTDs

2022 122022
2012委託調査結果(E) OSS調査対象

No,

OSS名

ソースコードURL（最終調査日）

No,

OSS名

ソースコードURL（最終調査日）

1 Javahttps://github.com/openjdk/（2022年９月27日）

20 Webkit

https://github.com/WebKit/WebKit（2022年９月27日）

2 PHP

https://github.com/php/php-src（2022年９月27日）

3 Python

21 Chromehttps://github.com/python/cpython（2022年10月13日）

4 Gitlabhttps://gitlab.com/gitlab-org/gitlab（2022年９月27日）

22 OpenOffice

5 Redminehttps://github.com/redmine/redmine（2022年９月27日）
http://svn.redmine.org/redmine/（2022年９月27日）

23 OpenSSL

https://github.com/chromium/chromium（2022年10月13日）
https://source.chromium.org/chromium（2022年10月13日）
https://github.com/apache/openoffice（2022年９月27日）
https://gitbox.apache.org/repos/asf/openoffice.git（2022年９月27日）
https://github.com/openssl/openssl（2022年９月27日）
https://git.openssl.org/（2022年９月27日）

6 Eclipse

https://github.com/eclipse（2022年９月27日）

7 Apache

16 Android

https://github.com/apache/httpd（2022年９月27日）
https://dlcdn.apache.org/httpd/（2022年９月27日）
https://github.com/nginx/nginx（2022年９月27日）
http://hg.nginx.org/nginx/（2022年９月27日）
https://github.com/samba-team/samba（2022年９月27日）
https://git.samba.org/samba.git/（2022年９月27日）
https://github.com/mysql/mysql-server（2022年９月27日）
https://dev.mysql.com/downloads/mysql/（2022年９月27日）
https://github.com/postgres/postgres（2022年９月27日）
https://www.postgresql.org/ftp/source/（2022年９月27日）
https://github.com/redis/redis（2022年９月27日）
https://redis.io/download/#redis-downloads（2022年９月27日）
https://github.com/torvalds/linux（2022年９月27日）
https://www.kernel.org/（2022年９月27日）
https://github.com/freebsd/freebsd-src（2022年９月27日）
https://cgit.freebsd.org/src/（2022年９月27日）
https://github.com/Debian（2022年10月13日）
https://sources.debian.org/（2022年10月13日）
https://github.com/aosp-mirror（2022年９月27日）
https://android.googlesource.com/（2022年９月27日）

17 mbedOS

https://github.com/ARMmbed/mbed-os（2022年９月27日）

18 Ubuntu

https://github.com/ubuntu（2022年９月27日）
https://kernel.ubuntu.com/git/（2022年９月27日）

19 Docker

https://github.com/docker（2022年９月27日）

8 Nginx
9 Samba
10 MySQL
11 PostgreSQL
12 Redis
13 Linux
14 FreeBSD
15 Debian24

Network Security https://github.com/nss-dev/nss（2022年９月27日）
https://hg.mozilla.org/projects/nspr（2022年９月27日）
Service (NSS)

25 GnuPG

https://github.com/gpg/gnupg（2022年９月27日）
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git（2022年
９月27日）

26 Mcrypt

http://mcrypt.cvs.sourceforge.net/（2022年９月27日）

27 Bouncy Castle

https://github.com/bcgit（2022年９月27日）

28 libsodium

https://github.com/jedisct1/libsodium（2022年９月27日）

29 7-zip

https://sevenzip.osdn.jp/download.html（2022年９月27日）

30 Keycloak

https://github.com/keycloak/keycloak（2022年９月27日）

13

委託調査結果(D)(E) 調査(D)での確認方法
 個々の規格文書ファイルに対して、検索ツールを用いて調査対象暗号アルゴリズ
ム名で検索 検索にかかった暗号アルゴリズムについて、内容を確認した上でその記載が参考情報扱いでないものについて、「当該暗号アルゴリズムは実装されている」と見なす
 検索にかからない、又は内容確認の結果、暗号アルゴリズムの記載が参考情報扱
いであるものについては、「当該暗号アルゴリズムは実装されていない」と見なす

 調査(E)での確認方法
 ソースコードURLのサイト内検索ツールを用いて調査対象暗号アルゴリズム名で検索※一部、ダウンロード・解凍した後にフォルダ内検索を実施したものあり 検索結果に表示される暗号アルゴリズムについて、ソースコードが存在する、実装されていることが明示されている、又は実装されていることが前提とした議論がある場合に「当該暗号アルゴリズムは実装されている」と見なす
 検索結果に表示されない暗号アルゴリズム、及び検索結果に表示される暗号アル
ゴリズムでも情報としてのみの表示としか確認できない場合は、「当該暗号アルゴ
リズムは実装されていない」と見なす
14利用実績－市販製品（公開鍵暗号（署名））※１※２※１集計対象209製品中、公開鍵暗号（署名）が101製品で実装（実装率：48.3% = 101/209）※２公開鍵暗号（署名）が実装された101製品に対する各アルゴリズムの実装率（実装率：100% = 101/101）

15

利用実績－政府系情報システム・規格（公開鍵暗号（署名））※※事務局補充調査結果を参考で追記

16利用実績－標準規格・民間規格（公開鍵暗号（署名））※※事務局補充調査結果を参考で追記

17利用実績－オープンソースソフトウェア（公開鍵暗号（署名））※※事務局補充調査結果を参考で追記

18利用実績－市販製品（公開鍵暗号（守秘・鍵共有））※１※２※１集計対象209製品中、公開鍵暗号（守秘・鍵共有）が76製品で実装（実装率：36.4% = 76/209）※２公開鍵暗号（守秘・鍵共有）が実装された76製品に対する各アルゴリズムの実装率（実装率：100% = 76/76） 19

利用実績－政府系情報システム・規格（公開鍵暗号（守秘・鍵共有））

20

利用実績－標準規格・民間規格（公開鍵暗号（守秘・鍵共有））

21

利用実績－オープンソースソフトウェア（公開鍵暗号（守秘・鍵交換））
n＝25, 83.3%
0%

10%

20%

30%

40%

50%

60%

70%

DH

0.0%
68.0%

RSA-OAEP

EC-MQV

100%

96.0%

RSAES-PKCS1-v1_5

RSA-KEM90%

100.0%ECDH
PSEC-KEM

80%

56.0%
8.0%
12.0%

22

利用実績－市販製品（共通鍵暗号（64ビットブロック暗号））※１※２※１集計対象209製品中、64ビットブロック暗号が56製品で実装（実装率：26.8% = 56/209）※２64ビットブロック暗号が実装された56製品に対する各アルゴリズムの実装率（実装率：100% = 56/56）

23

利用実績－政府系情報システム・規格（共通鍵暗号（64ビットブロック暗号））

24

利用実績－標準規格・民間規格（共通鍵暗号（64ビットブロック暗号））25

利用実績－オープンソースソフトウェア（共通鍵暗号（64ビットブロック暗号））
n＝26, 86.7%
0%10%CAST-128

40%

30%

50%

60%

70%

80%

0.0%

Hierocrypt-L1

0.0%

HIGHT

0.0%

92.3%

DES

96.2%

Blowfish

IDEA

100%

11.5%

Triple DES

GOST 28147

90%

15.4%

CIPHERUNICORN-E

MISTY1

20%

76.9%

30.8%

46.2%

26

利用実績－市販製品（共通鍵暗号（128ビットブロック暗号））※１※２※１集計対象209製品中、128ビットブロック暗号が172製品で実装（実装率：82.3% = 172/209）※２128ビットブロック暗号が実装された172製品に対する各アルゴリズムの実装率（実装率：100% = 172/172）27

利用実績－政府系情報システム・規格（共通鍵暗号（128ビットブロック暗号））28

利用実績－標準規格・民間規格（共通鍵暗号（128ビットブロック暗号））

29

利用実績－オープンソースソフトウェア（共通鍵暗号（128ビットブロック暗号））
n＝29, 96.7%
0%

10%

20%

30%

40%

50%

60%

AES

90%

100%

31.0%

Camellia

51.7%

CIPHERUNICORN-A

0.0%

CLEFIA

0.0%

Hierocrypt-3

0.0%SC2000

0.0%

SEED

48.3%

17.2%

TwofishSerpent80%

100.0%

ARIA

SMS4

70%

48.3%

20.7%

30

利用実績－市販製品（共通鍵暗号（ストリーム暗号・認証暗号））※１※２※１集計対象209製品中、ストリーム暗号・認証暗号が24製品で実装（実装率：11.5% = 24/209）※２ストリーム暗号・認証暗号が実装された24製品に対する各アルゴリズムの実装率（実装率：100% = 24/24）

31

利用実績－政府系情報システム・規格（共通鍵暗号（ストリーム暗号・認証暗号））32

利用実績－標準規格・民間規格（共通鍵暗号（ストリーム暗号・認証暗号））33

利用実績－オープンソースソフトウェア（共通鍵暗号（ストリーム暗号・認証符号））
n＝25, 83.3%
0%

10%

20%

ChaCha20

0.0%

Enocoro-128v2

0.0%

KCipher-2

50%

60%

70%

80%

90%

100%

4.0%

MUGI

0.0%

MULTI-S01

0.0%

RC4

SNOW

40%

76.0%

Decim

Rabbit

30%

88.0%

4.0%

12.0%

34

利用実績－市販製品（ハッシュ関数）※１※２※１集計対象209製品中、ハッシュ関数が154製品で実装（実装率：73.7% = 154/209）※２ハッシュ関数が実装された154製品に対する各アルゴリズムの実装率（実装率：100% = 154/154）

35

利用実績－政府系情報システム・規格（ハッシュ関数）

36利用実績－標準規格・民間規格（ハッシュ関数）

37利用実績－オープンソースソフトウェア（ハッシュ関数）
n＝30, 100.0%
0%

10%

20%

30%

RIPEMD-160

40%

50%

60%

70%

80%

90%

36.7%

SHA-1

86.7%

SHA-224

56.7%

SHA-256

96.7%

SHA-384

83.3%

SHA-512

86.7%

SHA3-256

36.7%

SHA3-384

40.0%

SHA3-512

40.0%

SHAKE128

26.7%

SHAKE256

36.7%

SM3

30.0%

Tiger

HAS-160

MD5

100%

16.7%

3.3%

93.3%

38

利用実績－市販製品（暗号利用モード／メッセージ認証コード）※１※２※１集計対象209製品中、暗号利用モード／MACが105製品で実装（実装率：50.2% = 105/209）※２暗号利用モード／MACが実装された105製品に対する各アルゴリズムの実装率（実装率：100% = 105/105） 39

利用実績－政府系情報システム・規格（暗号利用モード／メッセージ認証コード）40

利用実績－標準規格・民間規格（暗号利用モード／メッセージ認証コード）41

利用実績－オープンソースソフトウェア（暗号利用モード／メッセージ認証コード）
n＝29, 96.7%
0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

CBC

93.1%

CBC-MAC

25.9%

CCM

58.6%

CFB

48.3%

CMAC

44.4%

CTR

51.7%

CTS

27.6%

ECB

65.5%

GCM

86.2%

GMAC

37.0%

HMAC

100.0%

OFB

PC-MAC-AES

XTS

100%

51.7%

0.0%

37.9%

42

利用実績－市販製品（エンティティ認証）※１※２※１アンケート調査の有効回答中、エンティティ認証が19製品で実装※２エンティティ認証が実装された19製品に対する各アルゴリズムの実装率（実装率：100% = 19/19）

43

利用実績－政府系情報システム（エンティティ認証）

44

最後に
今後、同様の調査を実施する場合、以下の状況を考慮した設計が必要
 アンケート調査の有効性

10年前に実施した同様の調査と比べて、アンケート調査への協力が得られにくいという厳しい結果。以下の２つの理由が考えられる（１）暗号技術に精通する技術者の減少
調達する部品やモジュールに予め暗号技術が組み込まれており、自社側で暗号技術に関わる設計や開発を行う必要がなくなってきている結果、暗号技術に精通し、アンケート調査票に回答できる技術者が少なくなってきているという状況（２）技術情報を社外に公開する障壁の高さ
企業を取り巻く経営環境として、インシデントの発生が後を絶たない状況がある中で、企業におけるセキュリティポリシー、コンプライアンスポリシー、ビジネスポリシーの遵守に係るスタンスがより厳格な運用となっており、技術情報の公開の足かせとなってきている状況

 調査パネルの有効性
暗号技術全般についてのかなり深い知識を必要とする調査をインターネットアンケート調査で行うことは、信頼性の低い回答が多く含まれることが避けられない状況（１）ポイント目当てのモニターが情報を偽って、調査対象条件に当てはまらないにもかかわらず、アンケート
調査に無理に回答しようとする（２）正確に回答する意思があったとしても、知識が不十分であったり、認識に誤りがあったりするなどの理由
で適切な回答ができなかった可能性

 規格やOSSにおけるアルゴリズム名からの判定の難しさ（特にRSA暗号／RSA署名）
表記が統一されておらず、アルゴリズム名からだけでは厳密な判定ができないケースがある45