# PGP鍵アルゴリズムの動向調査レポート
## 更新履歴
| 日付 | 内容 |
| ---------- | ---- |
| 2026-05-10 | 初版作成 |
## 1. 調査の背景と目的
### 1.1 背景
PGP/OpenPGP は、メール暗号化・署名、ソフトウェア署名、認証等の幅広い場面で利用されている公開鍵暗号の標準である。鍵生成にあたっては複数の暗号アルゴリズム（RSA、DSA、ECC各種）と鍵長の組み合わせが選択可能であり、利用者は何らかの判断基準で選択する必要がある。
しかし、「どのアルゴリズム・鍵長を選ぶべきか」という問いに対する明確な公式ガイダンスは少なく、また各 Linux ディストリビューションの実態（パッケージ署名で何が使われているか）と、一般利用者への推奨が一致しない場合もある。
### 1.2 目的
本レポートは以下を目的とする：
1. PGP鍵のアルゴリズム選定に関する動向と参照可能な情報源を整理する
2. 主要な Linux ディストリビューションがパッケージ署名でどのアルゴリズムを採用しているかを調査する
3. これらの実態から、一般利用者が判断する際の参考材料を提供する
### 1.3 「ベストプラクティス」という用語について
調査の結果、PGP鍵のアルゴリズム選択について「ベストプラクティス」と呼べる単一の確立した文書は存在しないことが判明した。Riseup の "OpenPGP Best Practices" や各ディストリビューションのドキュメントは個別の推奨を提供するが、用途・互換性・保管方法によって最適解は異なる。
そのため、本レポートでは「ベストプラクティス」という言い方ではなく「動向と判断のフレームワーク」を提供する形を採る。
### 1.4 留意事項
本レポートは「事実」「解釈」「仮説」を区別して記載する。最終的な選択判断は読者自身が、自身の脅威モデル・運用環境・互換性要件に基づいて行う必要がある。
> **【筆者注記】利害関係の開示**
> 筆者は本稿で取り上げた組織・企業・団体・プロジェクト等との業務上の関係、出資関係、競合関係はない。
> 本稿はいかなる外部主体からの委託・資金援助も受けておらず、独立した調査・分析に基づく。
> 情報収集は公開されている情報を使用し、組織・企業・団体・プロジェクト等に個別にインタビュー等の聞き取り取材は行っていない。
> **本記事の作成プロセス**
> 本記事は、運営者とAIの協働により作成しています。作成プロセスおよび品質管理の詳細は、[[サイトポリシー#1.2 AI の利用について]]をご参照ください。
**本レポートの時間的限界**
本レポートは 2026年5月時点のスナップショットである。暗号アルゴリズムを取り巻く動向は、以下の要因により今後数年で大きく変化する：
- 量子計算機（PQC）への移行に関する各国ガイダンスの確定（2027〜2030年）
- NIST、BSI、CRYPTREC 等の公的ガイダンスの定期更新
- OpenPGP/LibrePGP エコシステムの動向
- 各 CSIRT/CERT 機関の鍵運用方針の変更
- 新たな暗号解析手法の登場
本レポートで参照した一次情報は、必ず最新版を直接確認することを推奨する。特に、本レポート公開から 1 年以上経過した時点で読まれる場合、結論の妥当性を再検証する必要がある。一次情報の URL とアクセス日付は脚注に明記している。
**特に PGP 鍵に関する情報は、最新情報を得てください**
---
## 2. 結論サマリー（先に結論）
### 2.1 事実として確認できる主要動向
- OpenPGP の最新標準 RFC 9580（2024年7月公開）では、**X25519 と Ed25519 が必須実装アルゴリズム**として位置付けられている[^1][^2]
- ドイツ BSI TR-02102-1（2026年1月版）等の公的ガイダンスは、ECC 系・RSA系のいずれも要求セキュリティ強度を満たせば許容、量子耐性を視野に入れた長期計画を推奨[^3]
- 日本 CRYPTREC暗号リスト（2026年3月30日改定）では、公開鍵暗号-署名として **EdDSA（Ed25519/Ed448 を含む）が電子政府推奨暗号リストに掲載**されている[^12]
- 米国 NIST SP 800-131A Rev.3 では、**2030年12月31日を境に 128ビット強度以上のアルゴリズムへの移行が推奨される**（ただし非対称暗号は PQC 移行と並行のため、即座の不許容ではなく deprecated 扱い）[^56]
- 米国 NSA CNSA 2.0 は、**国家安全保障システムの完全量子耐性化を 2035年**に設定[^57][^58]
- 主要 Linux ディストリビューションのパッケージ署名鍵は、**多くが RSA 4096 を採用している一方、Debian 13 (trixie) は 2025年に新規発行の Stable Release Key を Ed25519 に切り替えた**[^4][^5][^6][^7][^8][^46]
- GnuPG 2.3 以降のデフォルトは **Ed25519 主鍵 + Cv25519 副鍵**[^10]
- 暗号研究コミュニティ（Schneier、Bernstein/SafeCurves、Latacora 等）は **Ed25519 を一貫して肯定的に評価**しており、長期鍵には Latacora が **Ed25519 + ML-DSA-65 のハイブリッド**を推奨している（他機関の方針は分かれる）[^49][^51][^54][^55]
### 2.2 観察される構造
| 観点 | RSA 4096 | Ed25519 |
|---|---|---|
| 標準・規格（RFC 9580） | サポートされる | 必須実装 |
| Linuxディストリビューション署名 | 広く採用 | Debian 13 で採用、他は限定的 |
| 新規鍵生成のデフォルト | （旧 GnuPG） | GnuPG 2.3 以降 |
| 一般推奨 | 互換性重視で安全 | モダン・高速・コンパクト |
| 量子耐性 | なし（PQC へ移行必要） | なし（同上） |
### 2.3 一般利用者への示唆（解釈）
絶対的な「正解」がない以上、以下のような枠組みで考えるとよい：
- **既存システムとの互換性が最優先** → RSA 4096
- **モダンな実装の優位性を活かしたい** → Ed25519 + Cv25519（GnuPG 2.3+のデフォルト）
- **ハードウェアトークンの制約がある** → トークン仕様に従う（NIST P-曲線 や Brainpool が現実解）
- **量子耐性は別問題** → 現時点では古典系で運用しつつ、PQC 移行の動向を継続監視
---
## 3. 標準・規格の動向
### 3.1 RFC 9580（OpenPGP、2024年7月公開）
RFC 4880 の後継として 2024年7月に公開された OpenPGP の最新標準[^1]。RFC 9580 は X25519、Ed25519 を必須アルゴリズムとし、Ed448、X448、SHA-512、AES-256 等を推奨アルゴリズムとして規定している。
参照元による表現の揺れがあり、Wikipedia は必須要件を「X25519, Ed25519, SHA2-256 and AES-128」と記述[^27]、OpenPGP.org は「X25519, Ed25519, AES-OCB, and SHA2-256」と記述している[^2]。詳細は RFC 9580 本体を参照されたい。
**含意**：OpenPGP の標準は明示的に Ed25519/X25519 中心へとシフトした。RSA は依然としてサポートされているが、新規実装での必須要件ではなくなった。
### 3.2 各国公的機関のガイダンス
#### 3.2.1 ドイツ BSI TR-02102-1（2026年1月版）
ドイツ連邦情報セキュリティ庁（BSI）は暗号アルゴリズムの推奨ガイダンスを毎年更新している[^3]。要点：
- 適切なセキュリティ水準（120ビット以上）を満たすアルゴリズムを推奨
- ECC は楕円曲線の選定基準を満たすもの（Brainpool 系を BSI は伝統的に推奨）
- RSA は 3000ビット以上を要求
- 2025年版以降、長期保護用途には**ハイブリッド型 PQC との併用を強く推奨**
#### 3.2.2 日本 CRYPTREC暗号リスト
日本のデジタル庁・総務省・経済産業省による「電子政府における調達のために参照すべき暗号のリスト」（CRYPTREC暗号リスト LS-0001-2022R2、最終更新 2026年3月30日）[^12]。
**事実**（一次情報からの確認）：
電子政府推奨暗号リスト・現行暗号リストの公開鍵暗号-署名分野には、以下が掲載されている：
- DSA（注：FIPS 186-5 では廃止だが利用実績の観点から掲載継続）
- ECDSA
- **EdDSA**（Ed25519/Ed448 を含む）
- RSA-PSS
- RSASSA-PKCS1-v1_5
**重要な追加**：2026年3月30日改定で「**耐量子計算機暗号（PQC）リスト**」が新設された。鍵共有として ML-KEM-768/1024、共通鍵暗号として AES-192/256、ハッシュ関数として SHA2-384/512、SHA3-384/512 が掲載されている。一方、PQC リストの公開鍵暗号-署名は「該当なし」（2026年5月時点で検討中）。
別文書「暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準」（CRYPTREC LS-0003-2022r1）では、楕円曲線について以下のように規定されている[^13]：
- 新規にデータを暗号化する場合、**原則として 2040年までは 128ビット以上**のセキュリティ強度を使用する
- 2041年以降は 192ビット以上のセキュリティ強度が原則
- ただし、移行完遂を条件として、既存システムの継続利用や互換性維持のため、**2050年までは 128ビット強度の利用を許容**する（条件付き例外）
つまり、128ビット強度の楕円曲線（Ed25519 等）は、**原則として 2040年まで妥当、互換性維持を条件として 2050年まで延長可能**と評価されている。
**含意**：日本の電子政府推奨暗号リストにおいて、Ed25519 を含む EdDSA は正式に推奨されている。
### 3.3 GnuPG プロジェクトのデフォルト変更
GnuPG はバージョン 2.3.0（2021年4月リリース）から、**新規鍵生成のデフォルトを Ed25519主鍵 + Cv25519副鍵**に変更した[^10]。それ以前のデフォルトは RSA 3072（2.2.22以降）または RSA 2048。
GnuPG メイン開発者 Werner Koch 氏は以下のように述べている[^14]：
> The next default is ECC (ed25519+cv25519) which is supported by most OpenPGP implementations.
参考訳：次のデフォルトは ECC（ed25519+cv25519）であり、ほとんどの OpenPGP 実装でサポートされている。
**事実**：GnuPG のデフォルト変更は、ECC への移行が技術的に成熟し、実装互換性も実用水準に達したことを示している。
### 3.4 著名な専門家・セキュリティサイトの見解
公的機関のガイダンスに加えて、暗号研究コミュニティの著名な論者・サイトもアルゴリズム選定について発信している。本節ではこれらを整理する。
#### 3.4.1 Bruce Schneier（暗号研究者・セキュリティ論者）
NIST P-曲線（NIST 曲線）の定数の生成過程について、Bruce Schneier 氏は 2013年に以下の発言を残した[^49]：
> I no longer trust the constants. I believe the NSA has manipulated them through their relationships with industry.
参考訳：私はもはやこれらの定数を信用しない。NSA が業界との関係を通じてそれらを操作したと考える。
この発言は Snowden による NSA 文書公開（2013年）と同時期で、Dual_EC_DRBG にバックドアが仕込まれていた疑惑が暗号コミュニティに広がった文脈で出されたものである。
**留意**：本レポートの調査範囲では、Schneier 氏自身が 2013年のこの発言を撤回・修正した公的記録は確認できなかった。一方、暗号コミュニティ全般としては、Ed25519/Ed448 のような透明性の高い代替が普及したことで、「NIST 曲線への懸念」は当初ほど切迫した問題としては論じられなくなっている（3.4.2 節以降参照）。
#### 3.4.2 SafeCurves プロジェクト（Daniel J. Bernstein、Tanja Lange）
Curve25519 の設計者である Daniel J. Bernstein 氏と、Ed25519 の共同設計者の一人で SafeCurves を共同運営する Tanja Lange 氏が運営する **SafeCurves プロジェクト**は、楕円曲線の「安全性」を体系的に評価するサイトである[^51]。
SafeCurves は 2 種類の安全性概念を提示している[^52]：
1. **ECDLP セキュリティ**：楕円曲線離散対数問題の数学的困難さ
2. **ECC セキュリティ**：実装の落とし穴（サイドチャネル攻撃、無効点攻撃、ねじれ攻撃等）への耐性
SafeCurves は **NIST P-256（secp256r1）と NIST P-384（secp384r1）を「安全ではない」**と評価している[^51]。これは「ECDLP が解ける」という主張ではなく、「ECC セキュリティの観点から実装上の落とし穴が多い」という評価である。
一方、SafeCurves は以下の曲線を「安全」と評価している：
- Curve25519 / Ed25519
- Curve448 / Ed448
- E-521 など
**留意（中立性の観点から）**：SafeCurves の評価は暗号研究コミュニティで広く参照されているが、すべての標準化機関がこの評価を受け入れているわけではない。CA/Browser Forum は依然として NIST P-256/P-384/P-521 を ECDSA 鍵の許容曲線としている[^53]。また、OpenSSH や TLS 1.3 等の主要プロトコルは NIST 曲線のサポートを継続している。
#### 3.4.3 Latacora "Cryptographic Right Answers"（業界向け実務指針）
Latacora（セキュリティコンサルティング企業）が公開している "Cryptographic Right Answers" は、Colin Percival（2009年）、Thomas Ptacek（2015年）の系譜を継ぐ、業界で広く参照される暗号選択の指針である[^54]。
2018年版の主要な推奨[^54]：
> Asymmetric signatures: Use Nacl or Ed25519. ... Avoid: RSA-PKCS1v15, RSA, ECDSA, DSA; really, especially avoid conventional DSA and ECDSA.
参考訳：非対称署名：NaCl または Ed25519 を使え。…避けるべきもの：RSA-PKCS1v15、RSA、ECDSA、DSA。特に従来の DSA と ECDSA は避けよ。
**Latacora の RSA 回避の根拠**[^54]：
> Here are several reasons you should stop using RSA and switch to elliptic curve: RSA (and DH) drag you towards "backwards compatibility" (ie: downgrade-attack compatibility) with insecure systems. ... RSA begs implementors to encrypt directly with its public key primitive, which is usually not what you want to do.
参考訳：RSA を止めて楕円曲線に切り替えるべき理由はいくつかある：RSA（および DH）は安全でないシステムとの「後方互換性」（つまりダウングレード攻撃への互換性）にあなたを引きずり込む。…RSA は実装者にその公開鍵プリミティブで直接暗号化することをそそのかすが、それは通常やりたいことではない。
2024年に公開された **Post-Quantum 版**[^55]では、署名について以下を推奨：
> Latacora, 2024: You're probably fine with our 2018 advice for most applications, most signature keys have short life cycles, meaning that it's not vulnerable to "harvest now, decrypt later". If for some reason you have to deal with long-standing keys and signatures, we'd recommend Ed25519+ML-DSA-65, or P256+ML-DSA-65 if you depend on getting a thumbs-up from the government.
参考訳：Latacora 2024：ほとんどのアプリケーションでは、2018年の助言（Ed25519）で問題ない。ほとんどの署名鍵は短いライフサイクルを持つので、「今収集して後で復号」攻撃には脆弱でない。何らかの理由で長期間有効な鍵や署名を扱う必要がある場合は、**Ed25519 + ML-DSA-65 のハイブリッド**を推奨する。政府の承認が必要な場合は P256 + ML-DSA-65。
**含意**：Latacora の助言は、PQC 時代に向けても **Ed25519 を中核としつつ ML-DSA とのハイブリッドへ**という方向性を示している。
#### 3.4.4 NIST SP 800-131A Revision 3（2030年への移行スケジュール）
NIST Special Publication 800-131A Revision 3（initial public draft、2024年10月公開）は、暗号アルゴリズムの **2030年12月31日 / 2031年1月1日**を境とした移行スケジュールを規定している[^56]。ただし、対称暗号・ハッシュ関数と非対称暗号で扱いに差がある点が重要である：
- **対称暗号・ハッシュ関数の 128ビット強度移行**：2030年12月31日まで deprecated、2031年1月1日以降は legacy use または disallowed
- **非対称暗号（RSA、ECDSA 等）の 112ビット強度のもの**（RSA 2048、ECDSA P-224 等）：2030年に deprecated に格下げされるが、PQC（耐量子計算機暗号）への移行が並行して進められるため、disallowed や legacy use にはせず、利用は引き続き許容される
- **新規導入の推奨**：128ビット強度以上（RSA 3072、ECC P-384、Ed25519 等）への切り替えが推奨されるが、強制力は対称暗号・ハッシュ関数より弱い
この扱いの差は、NIST が「非対称暗号については古典暗号の強度引き上げと PQC への移行を二重に強制せず、PQC 移行の指針が整い次第そちらに統合する」方針を取っているためである[^59]。
つまり、**2030年以降の新規鍵生成では 128ビット強度以上が推奨されるが、RSA 2048 等の 112ビット強度の非対称暗号も即座に使用不可にはならない**点に注意が必要である。
#### 3.4.5 NSA CNSA 2.0（米国国家安全保障システム向け量子耐性スケジュール）
米国国家安全保障局（NSA）の Commercial National Security Algorithm Suite 2.0（CNSA 2.0）は、米国の National Security Systems（NSS）に対する量子耐性アルゴリズムへの移行スケジュールを規定している[^57][^58]。
主要なマイルストーン：
| 時期 | 対象 | 要件 |
|---|---|---|
| 2025年 | 全体 | PQC アルゴリズムのサポート・選好を開始 |
| 2027年1月1日 | 新規調達 | CNSA 2.0 準拠が必須 |
| 2030年12月31日 | ソフトウェア/ファームウェア署名 | CNSA 2.0 排他的使用 |
| 2030年12月31日 | ネットワーク機器（VPN、ルータ等） | CNSA 2.0 排他的使用 |
| 2033年12月31日 | OS、Web ブラウザ、クラウドサービス | CNSA 2.0 排他的使用 |
| 2035年 | 全 NSS | 完全な量子耐性化 |
**留意**：CNSA 2.0 は米国の NSS（国家安全保障システム）向けの規定で、一般の企業や個人を直接拘束するものではない。ただし、米国政府との取引がある組織や、長期保護が必要な情報を扱う組織にとっては実質的な参照基準となる。
**含意**：CNSA 2.0 のスケジュールは、欧州 BSI のハイブリッド PQC 推奨や、日本 CRYPTREC の PQC リスト新設とも整合する。**2030年代前半が古典暗号から量子耐性暗号への実質的な転換点**となる見込みである。
#### 3.4.6 整合的に読み取れる傾向
複数の独立した情報源（公的機関、暗号研究者、業界実務家）から、以下の整合的な傾向が読み取れる：
1. **Ed25519 への収斂**：NIST 曲線への懐疑から、設計透明性の高い Curve25519 系への評価が高まっている。BSI、CRYPTREC、Latacora、Bernstein らが Ed25519/Cv25519 を肯定的に評価しており、Schneier 氏は 2013年に NIST 曲線の定数への不信を表明している（推奨の強さは異なる）
2. **2030年が古典暗号の節目**：NIST SP 800-131A、NSA CNSA 2.0、BSI、CRYPTREC のいずれも 2030年前後を移行の重要な節目と位置付けている
3. **ハイブリッド PQC への移行（方針は分かれる）**：単純な「PQC への置き換え」ではなく、**古典暗号 + PQC のハイブリッド**が当面の現実解とされる傾向がある。ただし具体的な組み合わせは機関により異なる：Latacora は長期鍵に Ed25519 + ML-DSA-65 を推奨、CNSA 2.0 は ML-DSA-87 単独、BSI はハイブリッドを推奨するが組み合わせの選定は柔軟、CRYPTREC は ML-DSA を未採用（公開鍵暗号-署名 PQC は「該当なし」検討中）
4. **新規実装で RSA を採用する根拠は弱まりつつある**：互換性以外の理由では、Ed25519 が選ばれる傾向
ただし、これらは「動向」であって「確定した正解」ではない。ハードウェアトークンの対応状況、対象ユーザーの環境、長期運用要件等によって、依然として RSA 4096 が現実解となる場面は多い。
---
## 4. Linux ディストリビューションでの実態
主要な Linux ディストリビューションが、パッケージ・リポジトリの署名で実際に使用しているアルゴリズムを調査した。
### 4.1 Debian / Ubuntu
#### 4.1.1 現状の署名鍵
**事実**：
- Ubuntu Archive は **2026年1月時点で RSA 4096** を使用[^4]
> As of January 2026, the Archive keys use 4096-bit RSA.
参考訳：2026年1月時点で、アーカイブ鍵は 4096ビットRSAを使用している。
- Ubuntu Image Signing Key、CD Image Automatic Signing Key も RSA 4096
- Debian の archive keyring 最新版（2025.1）は trixie 用に新しい鍵を追加し、命名規則を `.gpg` から `.pgp` へ変更（OpenPGP 用語への統一）[^30]
- **Debian 13（trixie）では Stable Release Key が Ed25519 に切り替わった**（後述、実検証で確認）
**Kubuntu 26.04 LTS 環境での実検証（2026年5月）**[^45]：
`gpg --list-keys --keyring /usr/share/keyrings/ubuntu-archive-keyring.gpg` の実行結果から、現在 Ubuntu 環境にインストールされている archive keyring の内容が直接確認できた：
```
pub rsa4096 2012-05-11 [SC]
790BC7277767219C42C86F933B4FE6ACC0B21F32
uid Ubuntu Archive Automatic Signing Key (2012) <
[email protected]>
pub rsa4096 2012-05-11 [SC]
843938DF228D22F7B3742BC0D94AA3F0EFE21092
uid Ubuntu CD Image Automatic Signing Key (2012) <
[email protected]>
pub rsa4096 2018-09-17 [SC]
F6ECB3762474EDA9D21B7022871920D1991BC93C
uid Ubuntu Archive Automatic Signing Key (2018) <
[email protected]>
```
**Ubuntu に関して確認できた事実**：
- 3 つの archive key はいずれも **RSA 4096**
- 発行年は 2012年（2 つ）と 2018年（1 つ）
- いずれも有効期限が設定されていない（永続有効）
**Debian 13 (trixie) 環境での実検証（2026年5月）**[^46]：
`gpg --list-keys --keyring /usr/share/keyrings/debian-archive-trixie-stable.pgp` の実行結果：
```
pub ed25519 2025-03-24 [SC] [expires: 2033-03-22]
41587F7DB8C774BCCF131416762F67A0B2C39DE4
uid Debian Stable Release Key (13/trixie) <
[email protected]>
```
**Debian 13 に関して確認できた事実**：
- Debian 13 (trixie) の Stable Release Key は **Ed25519**（RSA 4096 ではない）
- 2025年3月24日発行、2033年3月22日まで（8年間）有効
- 鍵 ID `762F67A0B2C39DE4` は debian-archive-keyring 2025.1 の changelog 記述[^30]と一致
- 命名規則移行のため、`.pgp` と `.gpg` の両方の名前で同じ鍵が配置されている
**含意**：
主要 Linux ディストリビューションの archive signing key について、Ubuntu は 2012年/2018年発行の RSA 4096 鍵を継続使用している一方、**Debian 13（2025年8月リリース）では新規発行の Stable Release Key を Ed25519 に切り替えた**ことが実検証で確認された。これは主要ディストロが Ed25519 を実際に新規採用した事例として注目に値する。
**Ubuntu と Debian の対応の比較**：
| 項目 | Kubuntu 26.04 LTS | Debian 13 (trixie) |
|---|---|---|
| Archive Key アルゴリズム | RSA 4096 | **Ed25519** |
| 鍵発行年 | 2012年と2018年 | 2025年3月 |
| 有効期限 | 設定なし（永続有効） | 2033年3月（8年間） |
| GnuPG バージョン | 2.4.8 | 2.4.7 |
| アプローチ | 既存の RSA 4096 鍵を継続使用 | 新規鍵発行時に Ed25519 に切替 |
両者ともに Debian 系列であるが、対応方針に明確な差がある。Ubuntu は LTS の安定性を優先して既存鍵を維持し、Debian はメジャーバージョンアップ（12 → 13）の機会に新規鍵をモダンなアルゴリズムで発行した、と読める。これは「鍵交代の慎重さ」（5.2.2 節）の例外として、新規鍵発行時には Ed25519 が選択される時代に入っていることを示唆する。
#### 4.1.2 SHA-1 廃止（apt-get での扱い）
Debian は SHA-1 を弱い digest として扱い、署名検証で警告を発する方針に移行済み[^15]。SHA2-256 以上の使用が必須。
#### 4.1.3 Kali Linux
事実：Kali Linux Archive Automatic Signing Key も RSA 4096（2025年4月発行、2028年4月失効）[^5]。Debian/Ubuntu 系の標準的な構成を踏襲。
### 4.2 Fedora / RHEL
#### 4.2.1 現状の署名鍵
**事実**：Fedora の RPM 署名鍵は伝統的に RSA を使用[^16]。Fedora 38以降の鍵更新（2023〜）でも RSA が継続採用されている。
#### 4.2.2 SHA-1 廃止対応
Red Hat は Fedora/RHEL 向けに、署名鍵内の SHA-1 を使った subkey binding signature の更新作業を実施[^17]。鍵自体は RSA を維持しつつ、内部のハッシュアルゴリズムは SHA2 系に統一する方向。
### 4.3 Arch Linux
#### 4.3.1 マスターキーと開発者鍵
**事実**：Arch Linux は **Web of Trust モデル**を採用し、マスター署名鍵（5名の開発者が分散保有）と開発者・パッケージメンテナー鍵で構成される[^19][^20]：
> To determine if packages are authentic, pacman uses OpenPGP keys in a web of trust model. The current Master Signing Keys are found here. At least three of these Master Signing Keys are used to sign the Developers' and Package Maintainers' own keys.
参考訳：パッケージが本物かどうかを判定するため、pacman は web of trust モデルで OpenPGP 鍵を使用する。現在のマスター署名鍵はここで参照できる。これらのマスター署名鍵のうち少なくとも3つが、開発者およびパッケージメンテナー自身の鍵を署名するために使用される。
#### 4.3.2 アルゴリズムの実態
Arch Linux のマスターキーページ[^19]からはフィンガープリントが公開されているが、各マスターキーの具体的なアルゴリズム情報は同ページからは直接取得できなかった。過去に報告された Arch 開発者鍵では RSA 2048〜4096 の利用例が確認されている[^21]ため、現時点では RSA 系が中心と推察される。ただし、Arch コミュニティの自由度を踏まえると、開発者個人によっては Ed25519 等を採用している可能性もあり、断定は避ける。
### 4.4 openSUSE / SUSE
#### 4.4.1 現状の署名鍵
**事実**[^6][^7]：
- openSUSE Project Signing Key（2022年6月発行）：**RSA 4096**、2026年6月失効
- 2023年初頭に RSA 2048 から RSA 4096 へ全面移行
- SUSE Linux Enterprise も 2023年中盤に RSA 2048 → RSA 4096 へ移行（SLES 15 以降）
#### 4.4.2 移行の動機
openSUSE News（2023年1月）の説明[^7]：
> This switchover was necessary to meet current security recommendations.
参考訳：このスイッチオーバーは、現在のセキュリティ推奨を満たすために必要だった。
**解釈**：「現在のセキュリティ推奨」が具体的に何を指すかは明示されていないが、NIST SP 800-57 等の RSA 2048 が 2030年以降は不十分とされる勧告が背景にあると推察される。
### 4.5 各ディストリビューション比較表
| ディストリビューション | アーカイブ署名鍵アルゴリズム | 鍵長 | ハッシュ | 備考 |
|---|---|---|---|---|
| Debian (13/trixie) | **Ed25519**（2025年3月発行、実検証確認済[^46]） | Ed25519 | SHA2-256 | GnuPG 2.4.x 採用、2033年3月まで有効 |
| Ubuntu | RSA | 4096（実検証確認済[^45]） | SHA2-256 | 2012/2018年発行の鍵を継続使用、永続有効 |
| Kali Linux | RSA | 4096 | SHA2-256 | Debian系を踏襲 |
| Fedora/RHEL | RSA | 4096 | SHA2-256 | sq（Sequoia PGP）併用 |
| Arch Linux | 主に RSA（推定） | 多くは 3072〜4096 | SHA2-256 | Web of Trust モデル、開発者個別鍵 |
| openSUSE/SUSE | RSA | 4096 | SHA2-256 | 2023年に RSA 2048 から移行 |
注：上表は調査時点で確認できた情報をまとめたもの。Arch については個別鍵のアルゴリズムを網羅的には確認していない。
### 4.6 CSIRT/CERT 機関の PGP 鍵運用実態
セキュリティインシデント対応を業務とする CSIRT/CERT 機関は、日常的に PGP で機微情報を扱う最も先鋭な実務者である。これらの機関の鍵選択は、暗号アルゴリズム選定の実証的データとなる。
#### 4.6.1 実検証による調査結果
2026年5月10日に Kubuntu 26.04 LTS / GnuPG 2.4.8 環境で、各機関の公式サイトおよび公開鍵サーバから取得・インポートした鍵を `gpg --list-keys` で検証した結果[^60]：
**JPCERT/CC**（業務別 14 鍵を運用、うち実検証で確認できたもの）：
| UID（User ID） | アルゴリズム | 発行日 | 期限 |
|---|---|---|---|
|
[email protected] | RSA 2048 | 2009-06-02 | 期限なし |
|
[email protected]（Secretariat） | RSA 2048 | 2009-06-02 | 期限なし |
|
[email protected] / global-cc | RSA 2048 | 2009-04-08 | 期限なし |
|
[email protected]（ICS Security） | RSA 2048 | 2012-07-13 | 期限なし |
|
[email protected]（Information Coordination） | RSA 4096 | 2017-01-05 | 期限なし |
|
[email protected]（Incident Response） | RSA 4096 | 2024-06-12 | 2027-06-30 |
|
[email protected]（Vulnerability） | RSA 4096 | 2025-04-01 | 2028-03-31 |
|
[email protected]（EW Group） | RSA 4096 | 2025-06-04 | 2028-06-03 |
| cista-sec, cista-info, cista-noreply（CISTA 系 3 鍵） | RSA 4096 | 2025-06-04 | 2028-06-03 |
| csc-sec, csc-info, csc-anken（CSC 系 3 鍵） | RSA 4096 | 2025-06-04 | 2028-06-03 |
**主要な観察**：
- **2025年6月4日に 7 個の業務鍵を一斉発行**しており、組織的な鍵更新が行われた
- **2017年以降の新規発行鍵はすべて RSA 4096**
- 2009-2015年発行の RSA 2048 鍵は期限なしで継続運用
**CISA ICS-CERT**：
| UID | アルゴリズム | 発行日 | 期限 |
|---|---|---|---|
|
[email protected]（複数 UID 統合） | RSA 2048 | 2015-08-25 | 期限なし |
2015年発行の鍵を継続運用。Encryption Desktop 10.3.2 で生成。
**CERT/CC（カーネギーメロン大学）**：
| UID | アルゴリズム | 発行日 | 期限 | 鍵 ID |
|---|---|---|---|---|
|
[email protected] | RSA 4096 | 2022-09-29 | 2023-10-01 | F50A5453F549E723 |
|
[email protected] | RSA 4096 | 2024-10-01 | 2029-10-05 | A35600FB19853C9C |
CERT/CC は鍵を定期的に更新しているが、**アルゴリズムは一貫して RSA 4096**[^61]。
**INCIBE-CERT（スペイン）**：
| UID | アルゴリズム | 発行日 | 期限 |
|---|---|---|---|
|
[email protected]（IRIS-CERT） | RSA 4096 | 2012-05-16 | 2022-01-31（期限切れ） |
|
[email protected] | **Ed25519 + Cv25519** | 2024-06-04 | 2026-06-15 |
INCIBE-CERT は 2024年6月発行の業務鍵で **Ed25519** を採用。本サンプル中で Ed25519 を採用していた唯一の CSIRT。
**CERT-Bund（ドイツ BSI）**[^62]：
| UID | アルゴリズム | 発行日 | 期限 |
|---|---|---|---|
|
[email protected]（メイン業務鍵 2026） | RSA 4096 | 2025-12-01 | 2027-01-31 |
|
[email protected]（メイン業務鍵 2025） | RSA 4096 | 2024-11-15 | 2026-01-31（期限切れ） |
|
[email protected]（脆弱性受付 2026） | **ECDSA brainpoolP512r1** | 2026-01-05 | 2027-01-31 |
CERT-Bund は**業務種別で異なるアルゴリズムを採用**している。一般業務（incident response 等）には RSA 4096 を使用する一方、脆弱性受付業務では **brainpoolP512r1**（Brainpool 系 512 ビット楕円曲線）を採用。これは BSI が公式ガイダンス TR-02102-1 で Brainpool 系 ECC を推奨してきた立場（3.2.1 節参照）の**実装上の表明**と読める。
**CERT-FR（フランス ANSSI）**：
| UID | アルゴリズム | 発行日 | 期限 |
|---|---|---|---|
|
[email protected] | **RSA 3072** | 2012-11-19 | 期限なし |
CERT-FR は **RSA 3072** を採用している。RSA 4096 でも RSA 2048 でもなく、CRYPTREC LS-0003-2022r1 等で「128 ビット強度」とされる中間的な選択。2012年発行で 14年間継続使用。
**NCSC-NL（オランダ）**：
| UID | アルゴリズム | 発行日 | 期限 |
|---|---|---|---|
|
[email protected] /
[email protected]（NCSC-NL 2026） | **RSA 3072** | 2025-12-22 | 2027-02-01 |
NCSC-NL は **RSA 3072** を採用しており、UID に「2026」が含まれることから**年次ローテーション運用**を行っていることが推察される。CERT-Bund（毎年「CERT-Bund YYYY」として発行）と同じ運用パターン。
#### 4.6.2 集計結果
実検証で取得・インポートできた 23 鍵（主鍵）について[^60]：
```
主鍵のアルゴリズム集計：
RSA 4096 : 14 鍵（61%）
RSA 2048 : 5 鍵（22%）
RSA 3072 : 2 鍵（9%、CERT-FR、NCSC-NL）
EdDSA Ed25519 : 1 鍵（4%、INCIBE-CERT incidents）
ECDSA brainpoolP512r1 : 1 鍵（4%、CERT-Bund Vulnerability）
```
**RSA 系が 21/23 鍵（91%）、ECC 系が 2/23 鍵（9%）**。ECC 系の 2 鍵も Curve25519 系（INCIBE）と Brainpool 系（CERT-Bund）でアルゴリズムが分かれており、特定のモダンアルゴリズムへの収斂は見られない。
#### 4.6.3 観察される傾向
(1) **RSA 4096 が支配的選択**：CSIRT/CERT 機関の現役鍵の 61% は RSA 4096 を採用している
(2) **新規発行でも RSA 4096 が選ばれている**：JPCERT/CC は 2025年6月の大規模鍵更新でも RSA 4096 を選択。CERT/CC も 2024年10月の鍵更新で RSA 4096 を継続採用。CERT-Bund も 2025年12月発行のメイン業務鍵で RSA 4096
(3) **EU 圏 CSIRT は実装の多様性が高い**：
- ドイツ CERT-Bund は業務別使い分け（メイン業務 = RSA 4096、脆弱性受付 = brainpoolP512r1）
- フランス CERT-FR は RSA 3072（2012年から継続）
- オランダ NCSC-NL は RSA 3072（2025年12月発行、年次ローテーション）
- スペイン INCIBE-CERT は 2024年に Ed25519 を一部採用
各国の暗号政策の違いが鍵選択に反映されている可能性がある（特にドイツの Brainpool 採用は BSI の公式ガイダンスと整合）
(4) **古い RSA 2048 鍵の継続運用**：JPCERT/CC は 2009年発行の 2048 ビット鍵を 2026年現在も期限なしで維持。これは「鍵交代の慎重さ」（5.2.2 節）の実例と考えられる（仮説）
(5) **業務別役割分離**：JPCERT/CC は 14 個の業務別鍵を運用、CERT-Bund は業務別に異なるアルゴリズムを採用。CSIRT は用途ごとの鍵分離・アルゴリズム使い分けを実装している
(6) **年次ローテーション運用パターン**：CERT-Bund（毎年「CERT-Bund YYYY」として発行）、NCSC-NL（「NCSC-NL 2026」）に共通する**毎年鍵を更新する運用パターン**が観察される。これは長期間有効な鍵を使い続ける運用（JPCERT/CC の 2009年発行鍵継続使用、CERT-FR の 2012年発行鍵 14年継続使用）と対照的
#### 4.6.4 含意（解釈）
**機微情報を業務として扱う最も先鋭な実務者** が、2025-2026年時点でも新規発行鍵に RSA 4096 を支配的に選択している事実は、暗号アルゴリズム選択における「実用上の確実性」の重要さを示している。互換性最優先・長期安定運用の用途では、モダンな選択肢があってもなお RSA 4096 が選ばれる傾向にある。
一方、EU 圏 CERT 機関では実装の多様性が観察される。これは：
- 各国の公的暗号ガイダンス（BSI、CRYPTREC、ANSSI 等）の違いが反映されている
- 業務種別による使い分け（CERT-Bund のように一般業務と脆弱性受付で異なるアルゴリズム）が定着しつつある
- INCIBE-CERT のように、2024年以降の新規発行で Ed25519 を採用する事例も登場
CSIRT 業界全体として、**RSA 4096 が現役の主軸でありつつ、用途や国情に応じた多様性が併存する状況**にある。
#### 4.6.5 留保事項
本調査で取得できなかった機関：CERT-EU、NCSC-FI（フィンランド）、CIRCL（ルクセンブルク）、CSIRT.CZ（チェコ）、CERT.PL（ポーランド）、CERT.at（オーストリア）、CCN-CERT（スペイン政府向け）等。これらは公式 URL の自動取得に失敗し、鍵サーバ検索もカバーしきれなかった。EU 圏全体の網羅的調査には、各機関の公式ページから手動で鍵をダウンロードする追加作業が必要。本調査の結果は、ドイツ・フランス・オランダ・スペインの主要 CERT に限定されたサンプルとして解釈されたい。
---
## 5. 観察される傾向と分析
### 5.1 事実として観察される傾向
1. **調査対象とした主要 Linux ディストリビューションの archive signing key は、多くが RSA 4096 を採用している一方、Debian 13 (trixie) は 2025年に新規発行する Stable Release Key を Ed25519 に切り替えた**（2026年5月時点、実検証で確認）
2. **新規利用者向けには Ed25519 が事実上のモダン標準**となりつつある（GnuPG 2.3+のデフォルト、ProtonMail、Keybase 等が採用）
3. **量子耐性は未対応**：すべての現行鍵は古典暗号であり、量子コンピュータの実用化に対しては脆弱
4. **ディストロ間で対応に差異**：Ubuntu は既存の RSA 4096 鍵を継続使用、Debian は新規発行時に Ed25519 へ切替、というアプローチの違いが観察される
5. **CSIRT/CERT 機関は RSA 4096 を支配的に採用、ただし EU 圏で多様性**：JPCERT/CC は 2025年6月の大規模鍵更新でも RSA 4096 を選択、CERT/CC（CMU）も 2024年10月発行の最新鍵を RSA 4096 で運用、CERT-Bund（ドイツ）も 2025年12月発行のメイン業務鍵で RSA 4096。一方、EU 圏では CERT-Bund が脆弱性受付業務で brainpoolP512r1（BSI 推奨の Brainpool 系）、CERT-FR（フランス）と NCSC-NL（オランダ）が RSA 3072、INCIBE-CERT（スペイン）が 2024年に Ed25519 を一部採用、と各国の暗号政策に応じた多様性が観察される（4.6 節）
### 5.2 「なぜ Linux ディストリビューションは RSA を継続使用するのか」（解釈）
複数の合理的理由が考えられる：
#### 5.2.1 後方互換性
ディストリビューションの署名鍵は、古いシステム（数年〜10年前のインストール）を含むすべての利用者が検証できる必要がある。Ed25519 をサポートしない古い `gpg` 実装が現役である限り、移行は困難。
#### 5.2.2 鍵交代の慎重さ
署名鍵の変更は全利用者に影響する重大な変更で、各ディストリビューションは慎重に進める。一度確立した RSA 4096 を安易に変更しないのは、運用リスクの観点からは合理的。
ただし、Debian 13 が trixie リリースのタイミングで Ed25519 へ切り替えたように、メジャーバージョンアップなどの節目では新アルゴリズムの採用が進む可能性がある。
#### 5.2.3 「壊れていないものは触らない」原則
RSA 4096 は計算上の脆弱性が示されているわけではなく、現在の脅威モデルでは十分安全。アルゴリズム変更の便益（鍵サイズ、速度）が、変更コスト（互換性確認、運用検証）を上回るか不明。
#### 5.2.4 ハードウェアトークン互換性
リポジトリ署名鍵をハードウェア HSM に格納する場合、HSM の対応アルゴリズムに制約される。多くの HSM は RSA を最も広くサポート。
### 5.3 「個人利用者は何を選ぶべきか」（解釈と仮説）
判断のフレームワークとして、以下を提示する：
#### 5.3.1 用途別推奨
| 主な用途 | 推奨アルゴリズム | 理由 |
|---|---|---|
| メール暗号化（広い相手と互換性必要） | RSA 4096 または Ed25519+Cv25519 | 受信者の実装に依存 |
| Git コミット署名 | Ed25519 | GitHub 等が完全対応、コンパクト |
| パッケージ配布署名（個人OSS） | RSA 4096 | 受信者の互換性最優先 |
| 自己用ファイル暗号化 | Ed25519+Cv25519 | 互換性問題なし、高速 |
| ハードウェアトークン併用 | トークン仕様に依存 | YubiKey/Nitrokey等は Ed25519 対応、ZeitControl は NIST/Brainpool |
#### 5.3.2 鍵長の指針
CRYPTREC・BSI 等の公的ガイダンスを統合すると、以下の安全性評価が読み取れる：
| アルゴリズム | 安全性レベル（目安） | 2030年以降の見通し |
|---|---|---|
| RSA 2048 | 約 112ビット相当 | 非推奨化進行中 |
| RSA 3072 | 約 128ビット相当 | 2030年代までは妥当 |
| RSA 4096 | 約 140〜152ビット相当 | 2040年代までは妥当 |
| Ed25519 / Cv25519 | 約 128ビット相当 | 原則 2040年まで、互換性維持で 2050年まで延長可能（CRYPTREC評価）[^13] |
| NIST P-384 | 約 192ビット相当 | 2030年代以降も妥当 |
注：RSA 4096 の対称鍵相当強度は参照元によって 140〜152ビットの幅で記載される。NIST SP 800-57 系の推定値による。
---
## 6. 一般利用者への示唆
### 6.1 判断フレームワーク（参考）
以下の順で問いを立てると、選択肢が絞れる：
1. **互換相手は誰か？**
- 古い実装と通信が必要 → RSA 4096
- モダンな実装のみ → Ed25519+Cv25519
- ハードウェアトークン使用 → トークンの対応アルゴリズム
2. **鍵の保管はどこか？**
- ソフトウェアのみ → 任意のアルゴリズムが選択可能
- スマートカード/HSM → カードの対応アルゴリズム（多くは RSA、NIST、Brainpool）
- YubiKey 5 系 → Ed25519/Cv25519 対応
3. **長期運用を想定するか？**
- 5年以下 → 現行アルゴリズム（RSA 4096 / Ed25519）で十分
- 10年以上 → PQC への移行計画を視野に入れる
4. **何を優先するか？**
- 互換性 → RSA 4096
- 性能・コンパクトさ → Ed25519
- 設計の透明性（NIST 懸念回避） → Curve25519系（Ed25519/Cv25519）
- 公的標準への適合 → BSI なら Brainpool、CRYPTREC なら EdDSA含む複数選択肢
### 6.2 推奨される具体的構成（参考）
**個人用途のモダン構成（2026年時点、互換性問題が少ない場合）**：
```
主鍵：Ed25519 [SC]（署名・証明用）
副鍵 1：Cv25519 [E]（暗号化用）
副鍵 2：Ed25519 [S]（日常署名用）
副鍵 3：Ed25519 [A]（認証用、SSH等）
```
**互換性重視の構成**：
```
主鍵：RSA 4096 [SC]
副鍵 1：RSA 4096 [E]
副鍵 2：RSA 4096 [S]
副鍵 3：RSA 4096 [A]
```
ハードウェアトークン制約がある場合は、トークン仕様に合わせて RSA 4096 または NIST P-曲線 を選択する。
### 6.3 やってはいけないこと
公的機関のガイダンスから明確に避けるべきとされている選択：
- **DSA 1024 の使用**：NIST が 2013年に廃止
- **RSA 1024 の使用**：2010年代に解読可能性が指摘
- **SHA-1 によるハッシュ**：衝突攻撃が実用化済み（CRYPTREC では「運用監視暗号リスト」に分類）
- **MD5 によるハッシュ**：完全に破られている
---
## 7. 留保事項と議論の余地
### 7.1 本レポートの限界
- 各ディストリビューションの「内部での議論」までは追跡できていない（メーリングリスト等を網羅的に調査すれば、より深い背景が得られる可能性）
- 商用 PGP（Symantec/Broadcom 系）の動向は本レポートで扱っていない
- 量子耐性（PQC）への移行計画の詳細は別途調査が必要
- Arch Linux の各マスターキーや Debian の最新 archive key 以外の個別鍵のアルゴリズム確認は範囲外
### 7.2 議論の余地のある論点
#### 7.2.1 「ベストプラクティス」と呼べるか
調査の結果、**「これがベストプラクティスである」と一意に定まる文書は存在しない**ことが判明した。Riseup の "OpenPGP Best Practices"[^24] や各ディストリビューションのドキュメントは個別の推奨を提供するが、用途・互換性・保管方法によって最適解は異なる。
「ベストプラクティス」という概念自体が、暗号アルゴリズム選択においては適切でない可能性がある。むしろ「**判断のフレームワーク**」を提供することが、より誠実な情報提供である。
#### 7.2.2 NIST 曲線への懸念
Bernstein 氏らの SafeCurves プロジェクトが指摘する NIST P-曲線への懸念は、**ECDLP の数学的脆弱性ではなく ECC セキュリティ（実装堅牢性）の観点**である（3.4.2 節）。一方、OpenSSH や TLS 1.3 等の主要プロトコルが NIST 曲線を採用継続している事実は、専門家集団による事実上の信頼担保と読める。決定的な「NIST 曲線は危険」とまでは言い切れない状況である。
判断にあたっては：
- 互換性最優先なら NIST P-曲線を採用しても実害はないと考えられる
- 設計透明性を重視するなら Curve25519/Ed25519 が推奨される
- 公的標準への適合（特に米国向け）には NIST 曲線が必要
#### 7.2.3 量子計算機時代の到来
すべての古典暗号（RSA、ECC含む）は、十分な規模の量子計算機が実用化されれば破られる。複数の公的機関が独立に **2030年代を移行の節目**として設定している：
- **米国 NIST SP 800-131A Rev.3**：2030年12月31日に 128ビット強度未満を deprecated に格下げ。ただし対称暗号・ハッシュは 2031年以降 legacy use または disallowed、非対称暗号は PQC 移行と並行のため引き続き利用可能[^56]
- **米国 NSA CNSA 2.0**：2035年に NSS の完全量子耐性化、2027年には新規調達で必須[^57][^58]
- **ドイツ BSI**：2025年版以降、長期保護用途には**ハイブリッド型 PQC との併用を強く推奨**[^3]
- **日本 CRYPTREC**：2026年3月30日改定で PQC リストを新設、ML-KEM 等を電子政府推奨暗号として掲載[^12]
これらは独立した機関が、ほぼ同じ時期を移行点として設定しており、**2030年代前半が古典暗号から量子耐性暗号への実質的な転換点**となることを示唆する。今後 5〜10年で、本レポートの結論は大きく書き換わる可能性がある。
---
## 8. 参考情報源
### 8.1 標準・規格
- IETF RFC 9580（OpenPGP、2024年7月）
- IETF RFC 8410（Ed25519/Ed448/X25519/X448 識別子）
### 8.2 公的機関ガイダンス
- ドイツ BSI TR-02102-1（2026年1月版）
- 日本 CRYPTREC暗号リスト LS-0001-2022R2（最終更新 2026年3月30日）
- 日本 CRYPTREC LS-0003-2022r1（暗号強度要件）
- 米国 NIST SP 800-131A Revision 3（暗号アルゴリズム移行）
- 米国 NIST SP 800-57 Part 1 Revision 5（鍵管理推奨）
- 米国 NSA CNSA 2.0（2022年9月、量子耐性移行）
### 8.3 暗号研究コミュニティ
- SafeCurves プロジェクト（Daniel J. Bernstein、Tanja Lange）
- Bruce Schneier blog（暗号関連の論考）
- Latacora "Cryptographic Right Answers" シリーズ
### 8.4 実装側の文書
- GnuPG 公式ドキュメント、wiki
- Debian Wiki（SecureApt）、debian-archive-keyring パッケージ
- Ubuntu Security Documentation
- ArchWiki（GnuPG、pacman/Package signing）
- Riseup OpenPGP Best Practices
---
## 脚注
[^1]: RFC 9580: OpenPGP. https://www.rfc-editor.org/rfc/rfc9580.html (2026-05-09 閲覧)
[^2]: History of OpenPGP. https://www.openpgp.org/about/history/ (2026-05-09 閲覧)
[^3]: BSI TR-02102-1 "Cryptographic Mechanisms: Recommendations and Key Lengths" Version: 2026-01. https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf (2026-05-09 閲覧)
[^4]: Ubuntu archive integrity verification. https://documentation.ubuntu.com/security/software-integrity/archive-verification/ (2026-05-09 閲覧)
[^5]: A New Kali Linux Archive Signing Key. https://www.kali.org/blog/new-kali-archive-signing-key/ (2026-05-09 閲覧)
[^6]: openSUSE:Signing Keys. https://en.opensuse.org/openSUSE:Signing_Keys (2026-05-09 閲覧)
[^7]: New 4096 bit RSA signing key for Tumbleweed. https://news.opensuse.org/2023/01/23/new-4096-bit-signing-key/ (2026-05-09 閲覧)
[^8]: SUSE Signing Keys. https://www.suse.com/support/security/keys/ (2026-05-09 閲覧)
[^10]: GnuPG NEWS file (2.3.0 release notes). https://gnupg.org/download/release_notes.html (2026-05-09 閲覧)
[^12]: CRYPTREC暗号リスト. https://www.cryptrec.go.jp/list.html および LS-0001-2022R2 PDF https://www.cryptrec.go.jp/list/cryptrec-ls-0001-2022r2.pdf (2026-05-09 閲覧)
[^13]: CRYPTREC LS-0003-2022r1 暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準. https://www.cryptrec.go.jp/list/cryptrec-ls-0003-2022r1.pdf (2026-05-09 閲覧)
[^14]: Best practices for obtaining a new GPG certificate (gnupg-users mailing list). https://lists.gnupg.org/pipermail/gnupg-users/2021-March/064979.html (2026-05-09 閲覧)
[^15]: Teams/Apt/Sha1Removal - Debian Wiki. https://wiki.debian.org/Teams/Apt/Sha1Removal (2026-05-09 閲覧)
[^16]: Fedora Keeps You Safe. https://getfedora.org/security/ (2026-05-09 閲覧)
[^17]: Updating GPG keys for future Fedora and Red Hat Enterprise Linux releases. https://www.redhat.com/en/blog/updating-gpg-keys-for-fedora-and-rhel (2026-05-09 閲覧)
[^19]: Arch Linux Master Signing Keys. https://archlinux.org/master-keys/ (2026-05-09 閲覧)
[^20]: pacman/Package signing - ArchWiki. https://wiki.archlinux.org/title/Pacman/Package_signing (2026-05-09 閲覧)
[^21]: gpg and signing your own Arch Linux packages (Mike Williamson, 2016). https://mikewilliamson.wordpress.com/2016/02/04/gpg-and-signing-your-own-arch-linux-packages/ (2026-05-09 閲覧)
[^24]: OpenPGP Best Practices - riseup.net. https://riseup.net/en/security/message-security/openpgp/gpg-best-practices (2026-05-09 閲覧)
[^27]: Pretty Good Privacy - Wikipedia. https://en.wikipedia.org/wiki/Pretty_Good_Privacy (2026-05-09 閲覧)
[^30]: debian-archive-keyring changelog. https://launchpad.net/debian/+source/debian-archive-keyring/+changelog (2026-05-09 閲覧)
[^45]: Kubuntu 26.04 LTS（DISTRIB_DESCRIPTION="Ubuntu 26.04 LTS"、コードネーム resolute）環境での実検証結果。`gpg --list-keys --keyring /usr/share/keyrings/ubuntu-archive-keyring.gpg`、`gpg --version` の各コマンド出力。検証日：2026-05-09。
[^46]: Debian GNU/Linux 13 (trixie)（DEBIAN_VERSION_FULL=13.4、コードネーム trixie）環境での実検証結果。`gpg --list-keys --keyring /usr/share/keyrings/debian-archive-trixie-stable.pgp`、`gpg --list-keys --keyring /usr/share/keyrings/debian-archive-trixie-stable.gpg`、`gpg --version` の各コマンド出力。検証日：2026-05-09。Debian Stable Release Key (13/trixie) のフィンガープリントは 41587F7DB8C774BCCF131416762F67A0B2C39DE4、Ed25519、2025年3月24日発行、2033年3月22日まで有効。
[^49]: Bruce Schneier, "The NSA Is Breaking Most Encryption on the Internet" (2013-09-05), 本文記事ではなく同記事のコメント欄にて Schneier 氏自身による発言。https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html (2026-05-10 閲覧)
[^51]: SafeCurves: choosing safe curves for elliptic-curve cryptography. https://safecurves.cr.yp.to/ (2026-05-09 閲覧)
[^52]: Daniel J. Bernstein, Tanja Lange, "Safe curves for elliptic-curve cryptography". https://cr.yp.to/papers/safecurves-20240809.pdf (2026-05-09 閲覧)
[^53]: CA/Browser Forum Server Certificate Working Group Issue #578（NIST P-曲線が依然として ECDSA 鍵の許容曲線とされている件）. https://github.com/cabforum/servercert/issues/578 (2026-05-09 閲覧)
[^54]: Latacora, "Cryptographic Right Answers" (2018). https://www.latacora.com/blog/cryptographic-right-answers/ (2026-05-09 閲覧)
[^55]: Latacora, "Cryptographic Right Answers: Post Quantum Edition" (2024-07-29). https://www.latacora.com/blog/2024/07/29/crypto-right-answers-pq/ (2026-05-09 閲覧)
[^56]: NIST SP 800-131A Revision 3 (initial public draft) "Transitioning the Use of Cryptographic Algorithms and Key Lengths". https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar3.ipd.pdf (2026-05-09 閲覧)
[^57]: NSA Cybersecurity Advisory, "Announcing the Commercial National Security Algorithm Suite 2.0" (2022-09). 概要は postquantum.com 等で参照可能。https://postquantum.com/quantum-policy/nsa-cnsa-2-0-pqc/ (2026-05-09 閲覧)
[^58]: Entrust, "NSA announces new Post-Quantum resistant algorithm Suite 2.0 and Transition Timetable"（CNSA 2.0 のタイムライン詳細）. https://www.entrust.com/blog/2022/10/nsa-announces-new-post-quantum-resistant-algorithm-suite-2-0-and-transition-timetable (2026-05-09 閲覧)
[^59]: SafeLogic, "NIST Releases Draft of SP 800-131A Rev.3 for Upcoming Algorithm Transitions"（NIST SP 800-131A Rev.3 IPD における非対称暗号と対称・ハッシュ系の扱いの違いに関する専門家解説、2024年10月）. https://www.safelogic.com/blog/nist-releases-draft-of-sp-800-131a-rev3-for-upcoming-algorithm-transitions (2026-05-10 閲覧)
[^60]: 2026-05-10 に Kubuntu 26.04 LTS / GnuPG 2.4.8 環境で実施した CSIRT/CERT 機関の PGP 鍵調査結果。JPCERT/CC 公式サイト（https://www.jpcert.or.jp/english/ir/pgp.html）、CISA ICS-CERT 公式（https://www.cisa.gov/sites/default/files/documents/ICS-CERT_PGP_Pub_Key.asc）、CERT/CC GitHub Pages（https://certcc.github.io/pgp/）、INCIBE-CERT（https://www.incibe.es/en/incibe-cert/about-us/pgp-public-keys）、CERT-Bund 公式 BSI（https://www.bsi.bund.de/SharedDocs/Oeffentl_Schluessel_BSI/）、CERT-FR（鍵サーバ keys.openpgp.org）、NCSC-NL（https://www.ncsc.nl/contact/pgp-key、手動取得）から鍵を取得し、専用 GNUPGHOME にインポート、`gpg --list-keys --with-colons` で確定的にアルゴリズム判定。検証日：2026-05-10。総取得 23 鍵。
[^61]: CERT Coordination Center 公式 PGP 鍵情報（GitHub Pages）. https://certcc.github.io/pgp/ (2026-05-10 閲覧). 2024年10月発行の現行鍵：Key ID A35600FB19853C9C、RSA 4096、有効期限 2029-10-05。
[^62]: CERT-Bund（BSI）公式公開鍵ページ. https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Cyber-Sicherheitslage/Reaktion/CERT-Bund/Kontakt/kontakt.html (2026-05-10 閲覧). メイン業務鍵 CERT-Bund 2026 (DF72EDE41A7FD1DDADA47BF65FBADFB066259415、RSA 4096、2025-12-01 発行) および脆弱性受付鍵 CERT-Bund Vulnerability 2026 (67AAEC38DDB6EEAFFEC39E0F9342C4263BCE40E1、ECDSA brainpoolP512r1、2026-01-05 発行) を確認。