- 1.暗号技術
- 2.CRYPTREC暗号リスト
- 3.暗号技術の「2030年問題」
暗号には、「共通鍵暗号」「公開鍵暗号」「ハッシュ関数」の3つがあります。※ハッシュ関数を暗号に含めることには、議論がありますが。
1.暗号技術
1.1 共通鍵暗号
(1)共通鍵暗号について
・暗号する鍵と復号する鍵が同じである方式
・ZIPのパスワードで暗号化し、復号するのも共通鍵暗号。暗号化と復号が同じ鍵だから。
(2)シーザー（Caesar）暗号
・古くはシーザー（Caesar）暗号で、鍵となる値を13にするとROT13。※ROTはRotationの略
https://ja.wikipedia.org/wiki/ROT13
(3)CyberChef
❶CyberChefでROT13をやってみよう。
RecipeにROT13とし、Inputに変換したい文字を入れ、Recipeに処理を入れます。
https://gchq.github.io/CyberChef/
ROT13 Brute Forceを使うと、全てのパターン（26個）で実施してくれるので、CTF等で使うには便利でしょう。
❷Magic
Magicというのもあり、イイ感じに変換してくれる場合がある
たとえば、以下
72 101 108 108 111 --> hello
%E3%82%BD%E3%83%AB%E3%83%88 --> ソルト
1.2 ハッシュ関数
(1)ハッシュ関数
・暗号化の一つともいえる。ただし、不可逆性（元に戻せない）
・MD5やSHA-1など色々あるが、古い方式はコンピュータの進化により、解読される可能性が高い。SHA-256などをハッシュから元のデータを探す
・パスワードもハッシュ化して保存される。
ためしに、shadowファイルを見てみましょう。
cat /etc/shadow
・パスワードを暗号化しておらず、情報漏えいした事件も発生
https://xtech.nikkei.com/atcl/nxt/column/18/00001/01661/
(2)ソルト
・ソルト（塩）を付加することで、復元を難しくしている。
・パスワードのファイル（shadowファイル）で確認しましょう。（管理者でしかできないと思います）
#ユーザを作成。パスワードは同じ echo password | passwd --stdin user1 echo password | passwd --stdin user2 #しかし、ハッシュ値が変わっています。 cat /etc/shadow user1:$6$axBL.lN4$bVxFfRW./HXeVGOZrticDk94XZ6PNtKZ2V4AJXlqgxWpNrRla9./JwSxslhsmxUzeQ2SZ8HWyEcZLANNcsJ.h0:19374:0:99999:7::: user2:$6$5ziXSyug$bhnd/dTczpgeGxTKM6G2FKY5ZFRUZxWZ3oYOVidcSe8/cwbOk8q3n0fm1WeFAehrmqv4ZofasZ0cfgccw2UWs/:19374:0:99999:7:::
自分のパスワードをpasswdコマンドで変更し、shadowファイルの中身を比較してみよう。 ※事前にchmod o+r+x /etc/shadow として、一般ユーザがログを閲覧できるようにしています。（本当はやってはいけません）
①shadowファイルの内容をメモしておく
②PWを変える ※簡単なのはダメです。8文字以上の複雑なのを設定してください。
③PWを元に戻す
④shadowファイルの内容を確認し、元の値と比較。
[user20]$ passwd Changing password for user20. (current) UNIX password: #現在のパスワードを入れます。 New password: #新しいパスワードですが、辞書にない、8文字以上の複雑なパスワードを入れます。 Retype new password: passwd: all authentication tokens updated successfully. cat /etc/shadow
パスワードが同じでも、ソルトが違うので、違うハッシュ値になっているはずです。
また、ハッシュ値は、$を区切りとして、以下の順に並んでいます。
<ユーザ名>:$<ハッシュアルゴリズム>$<ソルト>$<ハッシュ値>
ハッシュアルゴリズムに関して、↑では$6とあるので、SHA-512でハッシュしていることがわかります。
| ID | ハッシュアルゴリズム |
|---|---|
| $1 | MD5 |
| $2a,$2b | Blowfish(Bcrpyt) |
| $5 | SHA-256 |
| $6 | SHA-512 |
余談ですが、上記の場合、パスワードは password であり、ソルトは $axBL.lN4 です。
cryptコマンドによって、crypt（パスワード、ソルト）の構文で実施すると、shadowファイルに記載されたハッシュ値が計算できます。
# perl -e 'print crypt("password", "\$6\$axBL.lN4");' $6$axBL.lN4$bVxFfRW./HXeVGOZrticDk94XZ6PNtKZ2V4AJXlqgxWpNrRla9./JwSxslhsmxUzeQ2SZ8HWyEcZLANNcsJ.h0
1.3 公開鍵暗号
・秘密鍵と公開鍵を使った暗号方式。
・RSA暗号がその代表
・RSAの仕組みは少し複雑です。
https://it-trend.jp/encryption/article/64-0056
1.4 エンコード
(1)エンコードについて
・エンコードとは、文字やデータをルールに基づき変換することです。
❶パーセントエンコーディング
URLやHTTPヘッダには日本語や「<」などが使えないので、ASCIIコードに変換します。さらに、パーセントエンコーディングしたことを示すために%を付けます。URLエンコーディングとも言われます。
| 文字 | ASCIIコード | パーセントエンコード |
|---|---|---|
| 1 | 31 | 1 |
| ＜ | 3c | %3c |
| ／ | 2f | %2f |
たとえば、以下のURLをデコードすると、どうなるでしょうか。
https://west-sec.com/crypto#4%E3%82%A8%E3%83%B3%E3%82%B3%E3%83%BC%E3%83%89
❷BASE64エンコード
電子メールはもともと、ASCII文字を想定していて、日本語文字などは送れません。そこで、BASE64エンコードによって、英数記号と+、/に変換します。
たとえば、元データ west を、BASE64エンコードすると d2VzdA== になります。このように、最後に=が入ることがあるのがBASE64エンコードの特徴です。=は、文字埋めの処理です。
(2)エンコードツール
・エンコードは、Windowsのコマンドプロンプトから、標準のコマンドcertutilでもできます。まあ、Webツールを使うのが便利でしょう。たくさんのサイトがありますが、以下のCyberChefがCTF利用者には人気です。
https://gchq.github.io/CyberChef/
Inputに変換したい文字を入れ、Recipeに処理を入れます。複数の処理を入れることも可能です。
たとえば、UTF-16LE（Encoding Text）に変換して、Base64（To Base64）をする場合は、2つを並べます。すると、Outputに処理結果が表示されます。処理については、左上にSearchがあるので、そこで処理を検索すると便利です。
1.5 PKI
・PKIは、デジタル署名と、証明書の理解が必要です。
・WEST-SECの証明書を見てみましょう。
https://west-sec.com
証明書の階層から、署名したのはISRG（=Let’s Encrypt）、件名にwest-sec.comが
記載。また、サブジェクトの公開鍵をみると、west-sec.comの公開鍵がわかります。
さらに、SHA-256指紋というのが、ディジタル署名です。
2.CRYPTREC暗号リスト
2.1 CRYPTRECとは
・デジタル庁・総務省・経済産業省が旗振り役となり、NICTとIPAに所属する暗号技術の専門家や大学教授などが技術的な評価を行って、「電子政府推奨暗号リスト（CRYPTREC暗号リスト）」などを策定。
・実際のCRYPTREC暗号リストは以下
https://www.cryptrec.go.jp/list/cryptrec-ls-0001-2022r2.pdf
2.2 注意点：「暗号の方式」と「鍵の長さ」
・「① 電子政府推奨暗号リスト」に記載されているのは、RSAやECDSAといった「暗号の方式（アルゴリズム）」の名前だけ。
・CRYPTRECの文書の冒頭にも、以下の注意書きがある。
| なお、利用する鍵長について、『暗号強度要件(アルゴリズム及び鍵長選択)に関する設定基準』の規定に合致しない鍵長を用いた場合には、電子政府推奨暗号リストの暗号技術を利用しているとは見なされないことに留意すること。 |
→つまり、いくら推奨リストにある方式を使っていても、鍵の長さが短ければ推奨リストを使っていることにはならない。
2.3 暗号リストの種類と意味
上記のリストでは、4つの分類に分かれている。
| 項番 | リスト名 | 意味 |
|---|---|---|
| 1 | 電子政府推奨暗号リスト（現行暗号リスト） | 安全性と実装性能が確認されており、市場での利用実績が十分ある、または今後の普及が見込まれるため、利用が「推奨」される暗号のリスト |
| 2 | 耐量子計算機暗号（PQC）リスト | 将来、現在の暗号を解読できるほど強力な量子コンピュータ（CRQC）が出現しても、それに耐えうることが確認された新しい暗号技術のリスト |
| 3 | 推奨候補暗号リスト | 安全性と性能は確認されているものの、実績などの面から現時点では推奨リストに入っていないが、将来的に推奨リストに昇格する可能性がある暗号のリスト |
| 4 | 運用監視暗号リスト | 解読リスクが高まるなどして「推奨すべき状態ではなくなった」ものの、古いシステムとの互換性を維持する目的のみに限り、継続利用が容認されている暗号のリスト。互換性維持以外の目的での利用は推奨されていない |
| Q.結局、どれを使えばいいの？ |
A.「1 電子政府推奨暗号リスト」が現実的です。
というのも、「2 耐量子計算機暗号（PQC）リスト」は、現時点では対応している市販製品やプロトコルがまだ限られています。そのため、直近は「1」の暗号を適切な鍵長で使いつつ、今後のシステムリプレース計画において「2」への移行準備を進めていくことになるでしょう。
2.4 実際のリスト
(1)現行暗号リスト
（出典：https://www.cryptrec.go.jp/list/cryptrec-ls-0001-2022r2.pdf）
(2)耐量子計算機暗号（PQC）リスト
3.暗号技術の「2030年問題」
3.1 「2030年問題」の全体像
(1)「2030年問題」とは何か？
・コンピュータの処理能力の向上により、現在の暗号方式が2030年頃を境に安全性を保てなくなる（危殆化する）問題です。
・実際、現在広く使われている暗号アルゴリズム（RSA-2048や楕円曲線暗号（224ビット）のECC-224など）は、NISTやIPAなどの標準化機関によって2030年頃までを推奨使用期限としています。
(2)それは量子コンピュータの影響？
・「2030年問題＝量子コンピュータに暗号が破られる問題」と考える人も多いようですが、厳密には別の問題です。ただ、暗号移行のタイミングが重なることから同時に議論されることが多くあります。
・2030年問題は量子コンピュータの有無にかかわらず、古典的な計算能力の進歩によって生じる問題です。
(3)言葉の整理
| 項目 | 意味 | 立場 |
|---|---|---|
| 2030年問題 | 【従来型コンピュータの進化】処理能力の向上により、2030年頃を境にRSA-2048などの現行暗号が安全性の基準を満たさなくなる問題 | 背景・期限 |
| 2035年問題 | 【量子コンピュータの実用化】暗号解読に特化した量子コンピュータの出現により、2035年頃を境に現行の公開鍵暗号が根本から破綻する脅威 | 背景・期限 |
| 危殆化 | 暗号方式や鍵長が古くなり、安全とはいえない状態になること | リスク |
| セキュリティ強度 | 暗号の破りにくさをビット数で表したもの。112bitより128bitの方が大幅に強い | 判断基準 |
| CRQC | 現行の公開鍵暗号（RSA・ECC）を実際に破れるほど強力な量子コンピュータ | 攻撃側・脅威 |
| Q-Day | CRQCが実用化され、現行の公開鍵暗号が破られるようになる日 | 脅威の到来時点 |
| HNDL | 今は解読できない暗号通信を保存しておき、将来CRQCで解読する攻撃 | 攻撃側・脅威 |
| PQC | CRQCが完成しても破られにくい数学的構造を持つ新しい暗号 | 防御側・対策 |
| 量子暗号 | 量子力学の性質を使って鍵を配送する技術。PQCとは別物 | 専用技術 |
| QKD | 量子暗号の代表例。量子の性質を使って盗聴検知しながら鍵を配送する仕組み | 専用技術 |
| ハイブリッド方式 | 従来暗号とPQCを組み合わせ、両方で安全性を確保する移行期の方式 | 移行策 |
| 鍵交換 | 通信を暗号化するための共通鍵を、通信相手と安全に共有する仕組み | 影響対象 |
| デジタル署名 | データの作成者や改ざんされていないことを確認する仕組み | 影響対象 |
| PKI | 電子証明書や認証局を使って、通信相手の正当性を確認する仕組み | 影響対象 |
| CA | 電子証明書を発行する認証局。CAの暗号が弱いと証明書全体の信頼が崩れる | 影響対象 |
| ML-KEM | PQCの鍵交換・鍵共有に使われる代表的な方式。旧称はKyber | PQC技術 |
| ML-DSA | PQCのデジタル署名に使われる代表的な方式。旧称はDilithium | PQC技術 |
| RSA | 現在広く使われる公開鍵暗号。鍵長を伸ばせば延命できるが、CRQCには弱い | 既存技術 |
| ECC | 楕円曲線暗号。RSAより軽量だが、CRQCには弱い | 既存技術 |
| AES | 共通鍵暗号の代表例。AES-256など十分な鍵長なら量子時代でも比較的強い | 継続利用可能 |
| SHA | ハッシュ関数の代表例。SHA-384やSHA-512などへの強化が検討対象になる | 継続利用可能 |
(4)「量子暗号」と「耐量子計算機暗号」は全くの別物
ニュースなどで「耐量子計算機暗号（PQC）」と「量子暗号」という2つの言葉を耳にすることがあります。名前は非常に似ていますが、実は全く異なる別物です。
■ 結論：一般企業が対策すべきは「PQC」
結論から言うと、一般企業やITシステム部門が「2030年問題」や将来の「Q-Day」に向けて移行計画を立てるべき対象は、ソフトウェアベースの「耐量子計算機暗号（PQC）」です。物理的な専用回線を必要とする「量子暗号」ではありません。
| ■Q.なぜ名前が似ているのか |
A.どちらも「将来、超高性能な量子コンピュータが完成しても、絶対に破られないセキュリティを作りたい」という同じ目的（ゴール）を目指して開発されているからです。
| ■Q.そもそも「量子暗号」とは何か？ |
A.・量子暗号（代表的な技術としてQKD：量子鍵配送など）とは、光の粒（光子）など、量子力学という「物理の法則」を利用して、絶対に盗聴されないように暗号鍵を送る通信技術のこと。
・最大の特徴は、量子の世界には「誰かが観測（盗み見）すると、その状態が変化して壊れてしまう」という絶対的な法則があります。これを利用し、通信の途中でハッカーがデータを盗み見ようとすると、データ自体が変化して瞬時に盗聴に気づく。
・具体的な実現方法として、専用の光ファイバーケーブルや特殊なレーザー通信機器を新たに敷設する。現時点では、国家の最高機密データや金融機関の拠点間通信など、コストをかけてでも物理的な専用線で傍受を防ぎたい、特殊かつ高度なセキュリティが求められる領域での実用化が中心です。
3.2 暗号危殆化のタイムリミットと現在進行形の脅威
想定される2つの脅威に関して、2030年に着目して整理します。
(1) 2030年問題に関連する2つの技術的要因
❶従来型コンピュータの進化（タイムリミット：2030年）
特別な量子コンピュータを持ち出すまでもなく、現在私たちが使っている通常のコンピュータ（スーパーコンピュータ含む）の性能向上だけで、「RSA-2048」などの現行暗号は2031年以降、実用的な時間内で解読されるリスクが跳ね上がります。 また、NISTや日本のCRYPTRECなどの公的機関が、安全性の担保を保証できなくなる（非推奨になる）期限が2030年頃です。
※本来の2030年問題はこちらのことです。
❷量子コンピュータの脅威（タイムリミット：2030年代〜）
現在の公開鍵暗号の数学的基盤（因数分解や離散対数問題）を、一瞬で解いてしまうアルゴリズムを実行可能な量子コンピュータをCRQC（Cryptographically Relevant Quantum Computer：暗号学に関連する量子コンピュータ）と呼びます。
※こちらは、2035年問題です。
Q. CRQCの実現はいつなのか？
A. 一般的には2030年代（早ければ2030年頃）と予測されています。このCRQCが稼働する日（Q-Day）が来ると、現行の公開鍵暗号はすべて無力化します。
| ■Q.もともとは、2030年じゃなく、2035年問題じゃなかった？ |
それは耐量子計算機暗号（PQC）への切り替えの件です。
https://www.nikkei.com/article/DGXZQOSG287AM0Y5A420C2000000/
日本政府(内閣官房国家サイバー統括室)の中間とりまとめ(2025年11月20日公表)では、「政府機関等の情報システムを、原則2035年を目途にPQCへ移行する」という方針が示されています。（出典：https://www.cas.go.jp/jp/seisaku/pqc/pdf/report_202511.pdf）
しかし、米国の国家安全保障局（NSA）は、署名関連やネットワーク機器について2030年という前倒し期限を設けていて、日本も、「2030年」を意識して早急に進めることが求められているでしょう。
(2)すでに始まっている脅威：HNDL攻撃のメカニズム
Q.量子コンピュータの完成が2030年代半ばなら、対策は2030年になってからでいいのでは？
A.HNDL（Harvest Now, Decrypt Later：今収穫し、後で解読する）攻撃があるため、早めの対処が求められる。
| ■攻撃のメカニズム 国家支援型ハッカーなどは、現在政府や企業がやり取りしている重要な暗号通信（TLSやIPsec）を、「今は解読できなくてもいいから」と割り切り、データを丸ごと自前のデータセンターに保存（収穫）しています。そして数年後、CRQCが完成した瞬間に、過去に遡ってすべての機密データを一斉に解読します。  |
よって、国家機密、特許、知的財産、長期の医療データなど、「10年後、20年後も秘密にしなければならないデータ」にとっては、2030年を待たずして「今この瞬間」がすでに脅威に晒されています。
3.3 対象となる暗号技術およびシステム
(1)対象となる暗号技術
すべての暗号技術が使えなくなるわけではありません。影響は主に公開鍵暗号方式、鍵交換、です。
| Q. AES256などの共通鍵暗号はどうなる？ |
A. 継続して使用可能です。 AES-256のような十分に長い鍵を持つ共通鍵暗号や、SHA-384/512などのハッシュ関数は、量子コンピュータに対しても高い耐性（量子耐性）を持つことが分かっています（※ただし、AES-128は2040年までにAES-256への移行が推奨）。
・以下、CRYPTRECの分類をもとに、対応が必要なものを整理しました。
| 技術分類 | 2030年問題への対処（期限：2030年） | CRQC（量子コンピュータ）への対処 |
|---|---|---|
| 公開鍵暗号（署名、鍵共有） | 【❌必須】 RSA-3072など、128ビット強度以上の鍵長への設定変更が必要 |
【❌必須】 鍵の長さに関わらず、現在の技術は破棄し、耐量子計算機暗号（PQC）への移行が必要 |
| 共通鍵暗号（AESなど） | 【⭕️原則不要】 AES-128やAES-256は、従来型コンピュータに対しては十分な強度を持つ |
【🔺必要に応じて設定変更】 「AES-256」などのより長い鍵への設定変更 |
| ハッシュ関数（SHA-256など） | 【⭕️原則不要】 SHA-256などで十分な強度を持つ |
【🔺必要に応じて設定変更】 「SHA-384」や「SHA-512」などへの設定変更 |
| 暗号利用モード、メッセージ認証コード等 | 【⭕️原則不要】 土台となる共通鍵暗号やハッシュ関数が安全であれば、これらも連動して安全 |
【⭕️原則不要】 土台となる共通鍵暗号（AES-256）やハッシュ関数（SHA-384等）をCRQC対応の強度に引き上げれば安全 |
(2)対象となる具体的な技術、システム
| Q. 実際にどんなシステムが影響する? |
A.
代表的なものを紹介します。
| 対象領域 | 深刻度 | 影響内容・詳細 | 具体的な対処 |
|---|---|---|---|
| PKI・電子証明書（X.509証明書） | 高 | CA（認証局）の証明書体系全体が対象。公開鍵から秘密鍵を逆算され、証明書が偽造される | ・CA自体の更新 ・端末・サーバーへの証明書の再発行 |
| TLS（HTTPS通信）/ IPsec（VPN） | 高 | 通信データの暗号化はAESを使っていても、鍵交換や通信相手の身元確認（デジタル署名）にRSAや楕円曲線暗号が使われている | ・Apache等のWebサーバの設定で、鍵交換の指定を変更 ・VPN機器（FortiGate・Cisco ASAなど）はファームウェア更新後に暗号設定を変更 |
| デジタル署名・コード署名 | 高 | ソフトウェアの署名鍵が逆算され、改ざんされたマルウェア等が「正規品」として出回る | ・より強力な署名証明書の再発行・取得 ・署名ツールやCI/CDパイプラインの設定更新 |
| SSH（リモートアクセス） | 高 | サーバー管理用の認証鍵が逆算され、システム内部への不正侵入や完全な乗っ取りを許してしまう | ・より強力な方式（Ed25519等）での鍵ペアのゼロからの再生成 ・サーバー側での古い認証アルゴリズムの無効化設定 |
| 無線LAN（Wi-Fi） | 中 | 電波が社外にまで漏れている場合、傍受により認証時の鍵交換が解読され、社内ネットワークへの侵入や通信の盗聴が可能になる | ・アクセスポイントの高強度モード（WPA3 192-bit等）への設定変更 ・連携する認証サーバー（RADIUS等）の証明書更新 |
| PCの暗号化（BitLocker等） | 低 | 保存データ自体の暗号化はAES等で強力だが、回復キー等の「ネットワーク上の受け渡し通信」が解読され、大元の鍵が漏洩する恐れがある | ・鍵管理サーバーやクラウド（MDM等）との通信経路の高強度化（TLS設定更新） ・連携する社内認証局の証明書更新 |
(3)具体的な被害の例
| Q.証明書の偽造とかって、大事（おおごと）になるのですか？ |
A.はい。マイナンバーカードを例に、順番に説明します。
■１．そもそもマイナンバーカードはどうやって身元を証明している？
マイナンバーカードのICチップの中には、「電子証明書」というデジタルな身分証明書が入っています。これには以下の2つの鍵がセットで使われています。
| 秘密鍵 | カードのチップの中に厳重に隠されており、外には絶対に出ない |
|---|---|
| 公開鍵 | 相手（国や銀行）に渡して、確かに本人かを確認してもらうために使う |
| Q.マイナンバーカードのICチップの中に公開鍵と秘密鍵の両方が入っているの？ |
A.はい、「公開鍵」と「秘密鍵」の両方がマイナンバーカードのICチップの中に入っています。ただし、秘密鍵は、ICチップ内の「絶対に外部から読み出せない（取り出せない）厳重なエリア」に保存されています。パスワード（暗証番号）を入力して電子署名を行う際も、データ処理はすべてICチップの内部で行われ、計算された「結果」だけが外に返される仕組み（耐タンパ性）になっています。
■２．具体的にどうやって悪さされるのか？
もし、2030年問題（コンピュータの劇的な性能向上）や量子コンピュータの登場を放置し、古い暗号（RSA-2048など）を使い続けた場合、以下のプロセスで悪用されます。
① 秘密鍵をコピーされる
圧倒的な計算力を持つコンピュータを使うと、世の中に公開されているあなたの「公開鍵」のデータから、カードの中にしかないはずの「秘密鍵」のデータを逆算して丸裸にすることができてしまいます。
| Q.別に私の公開鍵は公開してないけど |
A.e-Taxで確定申告をしたり、マイナポータルにログインしたりする際、相手のサーバーへあなたの公開鍵データが送信され、あちらのシステムに保管されています。通信経路での傍受（盗聴）されたり、保管先サーバーからの流出する可能性があるのです。
②カードなしで「なりすまし」が可能になる
秘密鍵のデータさえ手に入れば、攻撃者はあなたのマイナンバーカードを持っていなくても、自分のパソコン上で「あなたとしての電子署名」を自由に作り出すことができます。
| Q.今って、スマホでカードを読み取るなどして次のステップに進める。マイナンバーカードが無いと無理では？ |
A.国（e-Tax）や銀行のシステムは、あなたが「スマホの背面にカードをくっつけたかどうか」をカメラなどで物理的に確認しているわけではありません。攻撃者は自分のパソコン上に、e-Taxやマイナポータルと通信するための専用プログラムを作り、攻撃を成立させるでしょう。
■３．具体的な被害のシナリオ
・行政手続きの不正利用
e-Taxで勝手に還付金を申請されたり、マイナポータルにログインされて個人情報（税金や年金、健康保険の情報）をすべて抜き取られる。
・金融犯罪への巻き込み
オンラインで銀行口座を勝手に開設されたり、借金の契約などをあなたの名前でデジタル署名されてしまう。
(4) 暗号高度化に伴う「性能・運用面のトレードオフ」
「暗号強度を128bit（RSA 3072/4096bit等）へ引き上げる際、セキュリティは向上するが、システム全体のパフォーマンスと運用に大きな負荷（トレードオフ）が生じる。特にRSA 4096bitへの移行は、2048bit時と比較して計算負荷が急増し、認証サーバーやネットワーク機器のCPUを圧迫、認証遅延を引き起こすリスクがある（ソリトンシステムズ等のベンダーからも指摘されている）。また、認証局（CA）の鍵長変更は、既存のクライアント証明書の全失効・全再配布を意味し、情シス部門の運用負荷は極めて高い。」
(5)公開鍵暗号の暗号移行の進捗状況
※共通鍵暗号（AES）やハッシュ関数（SHA）は公開鍵暗号とは異なり、鍵長の確認・調整で対応できるため、以下の移行フェーズには含めていません
| 移行フェーズ | 進捗ステータス | 実態・現状の現実 |
|---|---|---|
| 【すでに対応済】 1024bit以下の排除 |
ほぼ完了 | 現代のOSやブラウザ、システムではすでにエラーとして弾かれる仕様になっており、事実上インターネット上からは排除 |
| 【移行対象】 2048bit等（112bit強度） |
現在の主流 | Webサイトの証明書（まだまだRSA-2048が主流）、放置された社内レガシーシステム、処理能力の低いIoT機器などで未だに手放せず、広く稼働 |
| 【2030年の壁への対応】 3072bit / ECC-256等（128bit強度） |
製品対応は完了・移行はこれから | OS・ブラウザ・ミドルウェア、ネットワーク製品、メガクラウド等での「機能としての対応」は完了。しかし、処理の重いRSA-3072への移行は進んでおらず、代わりに軽量な楕円曲線暗号（ECC-256）への切り替えが現実解として進みつつある段階（※ただし、NSAはECCへの移行を中間ステップとして推奨していない |
| 【CRQC対応】 PQC（耐量子計算機暗号） |
一部のみ | AWSやCloudflareなどの主要プラットフォームによる先行実装（ハイブリッド方式）や、一部の先進企業による検証フェーズに留まる |
3.4 ガイドラインと最新指針
この危機に対し、日米の政府機関は明確な規制とロードマップを提示しています。
(1)日本の指針：CRYPTREC（デジタル庁・総務省・経産省）
・CRYPTREC（読み方：クリプトレック）の基準では、セキュリティ強度をビット数で表し、以下のように制限を設けています。
※これは、古典的コンピュータへの耐性（2030年問題）の話であり、量子コンピュータへの耐性ではありません。
| セキュリティ 強度 |
主な 該当暗号 |
2022〜 2030年の扱い |
2031年〜 2040年の扱い |
2041年〜 の扱い |
|---|---|---|---|---|
| 112bit | 【RSA系（鍵長2048ビット）】 ・RSA-PSS ・RSASSA-PKCS1-v1_5 ・RSA-OAEP 【楕円曲線系（224ビット）】 ・ECDSA ・ECDH 【離散対数系（L=2048, N=224）】 ・DSA ・DH |
移行完遂期間 | 新規処理は 利用不可 （過去データの 復号のみ許容） |
利用不可 |
| 128bit | 【RSA系（鍵長3072ビット以上）】 ・RSA-PSS ・RSASSA-PKCS1-v1_5 ・RSA-OAEP 【楕円曲線系（256ビット等）】 ・ECDSA ・ECDH ・EdDSA（Ed25519など） 【離散対数系（L=3072, N=256）】 ・DSA ・DH 【ハッシュ関数】 ・SHA-256など |
利用可 | 利用可 | 移行完遂期間 |
| 256bit | 【共通鍵暗号】 ・AES-256 【ハッシュ関数】 ・SHA-512など 【RSA等】 256ビット強度を満たそうとすると、鍵長が非現実的なサイズ（15360ビット等）になるため実運用では使用されません。 |
利用可 | 利用可 | 利用可 |
※2031年になった瞬間にすべてが使えなくなるわけではなく、過去に暗号化された資産の「読み込み（復号）」に関しては2040年まで許容（互換性の維持）されています。
※いまRSA-2048からRSA-3072（128ビット）へ移行しても、上記の通り2041年には再び「移行完遂期間」に入ってしまうため、わずか10〜15年の延命措置にすぎないことが確定しています。
※ハッシュ関数の総合的なセキュリティ強度は、出力長（ハッシュ値のサイズ）の半分のビット数になるのが暗号学の基本ルールです。なので、SHA-256の場合、出力長256ビット ÷ 2 ＝ 128ビット強度とされます。
| ■Q.112bitと128bitってそれほど違わないような気もしますが |
A.112ビットと128ビットの差である「16ビット」の違いは、2の16乗＝65,536倍 です。仮に、最新のスーパーコンピューターを使って112ビットの暗号を解読するのに「1年」かかるとしたら、128ビットの暗号を解読するには「約6万5千年」かかる計算になります。
(2)国際的・米国の指針：NSA「CNSA 2.0」および NIST
米国国家安全保障局（NSA）は、国家安全保障システム向けのガイドライン「CNSA 2.0」で、以下の方針を示しています。※一般のPCやサーバではなく、あくまでも米国政府機関向けです。
■PQCへの移行義務化とNSAによる勧告一覧表
| 対象・項目 | 内容・対応期限 | 方針・詳細 |
|---|---|---|
| PQC（耐量子計算機暗号）の義務化： ソフトウェアやファームウェア | 2030年まで | NISTが標準化したPQCへの移行を完了することを義務付けています。 |
| PQC（耐量子計算機暗号）の義務化： Webブラウザやサーバー | 2033年までに | NISTが標準化したPQCへの移行を完了することを義務付けています。 |
| ECC（楕円曲線暗号）への移行停止勧告 | 即時（PQCへの直接移行） | NSAは「現在RSAを使っている組織は、わざわざコストをかけて楕円曲線暗号（ECC）に移行するな。その資金と時間は、直接PQCへ移行するために使いなさい」と明言しています。 |
3.5 PQCに関する製品の対応状況
世界は「既存の暗号（RSA/ECC）にPQCを重ね書きする『ハイブリッド方式』」を現実解として動き出しています。
(1)「ハイブリッド方式」とは？
通信を保護する際に「実績のある従来の暗号（ECCなど）」と「新しい耐量子計算機暗号（PQC）」の両方を同時に使い、二重に鍵をかける仕組み。
Q.なぜわざわざ2つの暗号を重ねるのか
A.新しいPQCは、量子コンピュータからの攻撃は防げる。しかし、まだ歴史の浅い新しい数学を使っているため、思わぬ未知の脆弱性が見つかるリスクがゼロではないため。
(2)移行後の具体的な通信の仕組み（TLS 1.3）
・Webサーバーの通信プロトコルは「TLS 1.3のまま」で移行が可能。
・加えて、鍵交換のハイブリッド化として、従来型の「X25519（楕円曲線）」と、NIST標準のPQC「ML-KEM（旧Kyber）」の両方を使って二重に鍵を作る
・サーバー証明書のPQC化として、身元を証明するデジタル証明書（ML-DSAなど）への置き換えを行う。ただ、緊急度は鍵交換（HNDL対策）より後に設定されています。
(3)主要製品・クラウドサービスの最新対応状況
PQCを組み込んだ製品は、私たちが気づかないうちにすでに社会に実装され始めています。
❶ネットワーク機器（FortiGateなど）：
主要ベンダーであるFortinetは、2030年問題に対応していて、以下のように、DHグループ19以上を選ぶことになります。
■DH鍵共有におけるセキュリティ強度分類
| グループ番号 | 内容 | 強度 |
|---|---|---|
| 1、2、5 | 旧来のDH（1024〜1536bit） | 危殆化済・使用禁止 |
| 14 | DH 2048bit | 112bit強度（2030年問題の対象） |
| 19、20 | ECDH P-256、P-384 | 128bit・192bit強度 ✅ |
| 21 | ECDH P-521 | 256bit強度 ✅ |
・また、FortiOS 7.4以降でIPsec VPNにおけるPQC（ハイブリッドモード）をすでにサポートしています。ファームウェアを最新に保ち、設定を有効化することで、拠点間通信に量子耐性を持たせることができます。
❷メガクラウド（AWSなど）：
AWSは対応の最前線にいます。AWS KMSやSecrets Manager、ACMでハイブリッドPQCをサポートしているほか、Amazon CloudFront（CDN）では、既存のすべてのTLSセキュリティポリシーにおいて、ユーザー側の追加料金や設定変更なしで「自動的にハイブリッドPQC鍵交換」が有効化されています。
❸CDN・ブラウザ（Cloudflare / Chromeなど）：
Cloudflareもエッジネットワーク全体でPQCをデフォルト有効化しており、Google ChromeやEdgeなどのモダンブラウザもこれに標準対応しています。
❹証明書発行機関（認証局：CA：DigiCert / Let's Encryptなど）
たとえば、最大手であるDigiCertは、すでに自社のプライベート認証局（社内ネットワークやIoT向け）において、NISTが標準化した最新のPQC署名（ML-DSA）を用いた証明書の発行をサポートし始めている。パブリック（一般Webサイト向け）な証明書についても、インフラの完全なPQC移行目標を2029年に設定しており、ブラウザ側の要件や国際的な標準化が整い次第、速やかにハイブリッド証明書などを展開できる体制を構築。
・たとえば、「WEST-SEC」のサイト（はてなブログ）の証明書を見てみましょう。以下のように、Amazonが発行する証明書
・開発者モードで見ると、セキュリティ対策情報が確認できます。
整理すると、以下になります。※なんと、CRQCにもかなり対応しています。
| 技術分類 | 詳細 | 2030年問題への対応 | CRQCへの対応 |
|---|---|---|---|
| 公開鍵暗号（鍵共有） | X25519 / ML-KEM-768（ハイブリッド） | 【⭕ クリア】X25519により十分な強度を確保。 | 【⭕ クリア (最先端)】量子耐性を持つML-KEMが組み込まれており、HNDL攻撃も防御可能 |
| 公開鍵暗号（署名・証明書） | ECDSA 256 | 【⭕ クリア】128ビット強度を満たしているため問題なし。 | 【❌ 将来的に移行必要】署名にはまだPQCが使われていないため、量子コンピュータ完成時には偽造リスクが生じる |
| 共通鍵暗号 | AES_128 | 【⭕ クリア】AES-128は従来型コンピュータに対して十分な強度。 | 【🔺 必要に応じて変更】将来的に最高強度を求めるならAES_256への引き上げが推奨 |
| 暗号利用モード | GCM | 【⭕ クリア】安全なモード | 【🔺 土台に依存】土台がAES_128なので、CRQC対応を完璧にするならこちらも対応 |
3.6 取るべきアプローチ
(1)基本方針
選択肢としては、以下の3つがあります。
| 項番 | 選択肢 | 長所 | 短所 |
|---|---|---|---|
| 1 | RSAのまま鍵を長くする（RSA-3072など） | 設定の数字を変えるだけで互換性が高く、移行コストがほぼゼロ。 | 計算負荷が極端に重くなり、サーバーの通信速度低下や電気代高騰を招く。かつ、量子コンピュータには無力（ただの延命）。 |
| 2 | 楕円曲線暗号（ECC）に切り替える | 処理が非常に軽くスピーディ。 | アルゴリズムが変わるため古いIoT機器などが対応せず、改修が必要。かつ、量子コンピュータには無力。 |
| 3 | 耐量子計算機暗号（PQC） | 将来の量子コンピュータ（CRQC・HNDL）にも永続的に対応できる「理想の正解」。 | 2024年に標準化されたばかりの最新技術であり、暗号の「データサイズ」が非常に大きいため、古いネットワーク機器やメモリの少ないレガシーシステムでは処理しきれずにパンクする（動作不良）リスクがある。 |
最終的な理想はすべてのシステムを3つめのPQCに移行することです。
(2)ロードマップ例
技術的な過渡期である現在は、段階的な移行になるでしょう。
【第1段階】2030年問題への対応
・ 電子政府推奨暗号リスト（現行暗号リスト）に掲載されている暗号方式を採用する。RSA系であれば、RSA-3072以上（RSA-PSS、RSASSA-PKCS1-v1_5、RSA-OAEPなど）や、楕円曲線系であれば、ECDSA（P-256）やECDH（P-256）など。
・加えて、「十分な長さの鍵」を組み合わせる（＝ 2030年以降は 128ビット強度以上となる RSA-3072 や ECDSA-256 などを設定する）
【第2段階】量子コンピュータ（CRQC）出現への対応
耐量子計算機暗号（PQC）リストにある暗号技術を採用する
| Q.PQCの場合、鍵長はどうすればいいの？ |
A.PQCは数学的な構造がこれまでの暗号（RSAや楕円曲線）と全く異なるため、「〇〇ビット以上なら安全」という従来のルールに当てはめることができません。そのため、CRYPTREC側も「とりあえず今は、従来の鍵長ルールはPQCには適用しない（見直し中）」としています。
(3)製品ごとの方針
❶クラウド・SaaS
AWSやCloudflareなどの領域は、プラットフォーマーが自動的に裏側をPQCハイブリッドにアップデートしてくれるため、自然体でその仕組みの恩恵を享受すればいい。特にやるべきことはない
❷オンプレミスのネットワーク機器
定期的にOSやファームウェアを最新にし、必要に応じてPQCの設定を反映する
❸認証局及び証明書
・CA自体の更新： CA（認証局）自身の鍵ペアを強力なアルゴリズムで再生成し、証明書を更新する（または新しいCA階層を構築する）。
・端末・サーバーへの再発行： 各対象機器で新しい鍵ペア（CSR）を作成し直し、新しい証明書を発行・配布して入れ替える。
❹自前のWebサーバ（オンプレミスやIaaS上の独自アプリケーション）
クラウドの恩恵を自動で受けられない自前構築のWebサーバ（Apache、Nginx、IISなど）は、管理者が主体的に以下の設定変更やアップデートを行う必要があります。
a)「TLS 1.3」への完全移行
b)暗号ライブラリの更新と「ハイブリッド鍵交換」の有効化（設定変更）
→OpenSSLなどを、PQCに対応した最新バージョンへアップデートし、nginx.confなどの書き換え（通信確立時の鍵交換アルゴリズムとして「X25519（従来の楕円曲線暗号）」と「ML-KEM（新しいPQC）」使うなど）
c)サーバー証明書の更改
❺無線LAN（Wi-Fi）機器・アクセスポイント
WPA3対応機器を標準とし、古いWPA2専用機器を計画的にリプレースし、CiscoやArubaなどのネットワーク機器ベンダーからPQC対応（量子耐性を持った新しいWPA規格など）のファームウェア・アップデートが提供された段階で、順次アクセスポイントのOSを更新する
「2030年というタイムリミットを頭の片隅に置きながら、日々のシステム更新サイクルの中で自然に最新設定へと滑り込ませていくのがいいと思います
