# OpenPGP と LibrePGP の方向性分岐——実装エコシステムの現状
## 更新履歴
| 日付 | 内容 |
|---|---|
| 2026-05-10 | 初版作成 |
---
## 1. 調査の背景と目的
### 1.1 背景
OpenPGP は、メール暗号化・署名、ソフトウェア署名、認証等の幅広い場面で利用されている公開鍵暗号の標準である。その仕様を巡り、**IETF OpenPGP Working Group**（標準化機関側）と **GnuPG プロジェクト**（最も広く利用されている実装の上流）の間で、2023年以降に方向性の分岐が顕在化した。
IETF 側は 2024年7月に **RFC 9580**（OpenPGP の現行最新版、v6 鍵フォーマット導入）を公開した一方、GnuPG メイン開発者の Werner Koch 氏は 2023年11月に **LibrePGP** を提唱し、RFC 9580 ではなく独自の v5 鍵フォーマット路線を採る方針を示した。
この分岐は、ユーザーが利用する OS・メールクライアント・Web メールサービスのデフォルト挙動に影響を与える。また、複数の Linux ディストリビューションのパッケージメンテナーが共同で運営する **FreePG プロジェクト**が、ダウンストリーム側からの集合的な「補正機構」として機能している。
### 1.2 目的
本レポートは以下を目的とする。
1. RFC 9580 と LibrePGP の分岐の経緯を整理する
2. FreePG プロジェクトの存在と機能を明らかにする
3. OS・実装別の立場（Linux、Windows、macOS、Thunderbird、ProtonMail）を整理する
4. 実検証結果（FreePG パッチの効果、Debian 13 の Ed25519 採用）を提示する
5. ユーザーへの影響を整理する
### 1.3 留意事項
本レポートは「事実」「解釈」「仮説」を区別して記載する。実装エコシステムの状況は流動的であり、本レポートの記述は 2026年5月時点のものである。
> **【筆者注記】利害関係の開示**
> 筆者は本稿で取り上げた組織・企業・団体・プロジェクト等との業務上の関係、出資関係、競合関係はない。
> 本稿はいかなる外部主体からの委託・資金援助も受けておらず、独立した調査・分析に基づく。
> **本記事の作成プロセス**
> 本記事は、運営者とAIの協働により作成しています。作成プロセスおよび品質管理の詳細は、[[サイトポリシー#1.2 AI の利用について]]をご参照ください。
---
## 2. 結論サマリ
### 2.1 事実として確認できる主要動向
- 2023年11月、GnuPG メイン開発者の Werner Koch 氏が「LibrePGP」を提唱[^1]
- 2024年7月、IETF OpenPGP WG は **RFC 9580** を公開（v6 鍵フォーマット導入）[^2]
- GnuPG は LibrePGP 側に立ち、RFC 9580 はサポートしない方針[^1]
- Sequoia PGP、ProtonMail（OpenPGP.js / GopenPGP）等は RFC 9580 を実装[^14][^15]
- Mozilla Thunderbird は **RNP**（C++ 実装）を内蔵し、RNP は LibrePGP の公式サポーター[^7][^8]
- 主要 Linux ディストロ（Arch、Debian、Fedora、Gentoo、NixOS、Ubuntu）は **FreePG プロジェクト**のパッチを採用し、デフォルトで OpenPGP（RFC 9580）互換のアーティファクトを生成する[^4]
- Debian 13 (trixie) の Stable Release Key は **Ed25519**（2025年3月発行、実検証で確認済）[^16]
- Kubuntu 26.04 LTS / GnuPG 2.4.8 環境での `--full-generate-key` で AEAD: OCB が抑制されることを実検証で確認（FreePG パッチの効果）[^17][^18]
- **GnuPG 2.5.19（現行 stable[^30]、PQC 対応）でも、通常鍵生成のデフォルトは v4 鍵**であることを実検証で確認[^31]
- **GnuPG 2.5.19 で PQC 鍵生成（Kyber 768 ハイブリッド）を実行すると、「v4 主鍵 + v5 PQC 副鍵」のハイブリッド構造が生成される**ことを実検証で確認[^31]
### 2.2 観察される構造
| 観点 | RFC 9580（OpenPGP） | LibrePGP |
|---|---|---|
| 鍵フォーマット | v6 を新規導入 | v5（PQC 副鍵で生成）/ v4（GnuPG 2.4.x / 2.5.x の通常鍵生成のデフォルト[^28][^31]） |
| 推進主体 | IETF OpenPGP WG | Werner Koch 氏（GnuPG） |
| AEAD モード | EAX/OCB/GCM（実装可能） | OCB（type 20 パケット、上流デフォルト） |
| 主な実装 | Sequoia PGP、ProtonMail、OpenPGP.js、GopenPGP | GnuPG（上流）、Gpg4win、RNP（Thunderbird 内蔵） |
| Linux ディストロのデフォルト | **こちら側**（FreePG パッチ経由） | 明示的指定でのみ生成 |
注：FreePG パッチを適用すると、GnuPG はデフォルトで OpenPGP（RFC 9580）互換のアーティファクトを生成し、LibrePGP 機能はオプトインとなる[^4]。
### 2.3 ユーザーへの含意（解釈）
- **Linux ユーザー**：主要ディストロを使う限り、デフォルトで OpenPGP（RFC 9580）互換が確保される（FreePG パッチによる）。ユーザーはこの事実を通常意識しない（透過的）
- **Windows ユーザー**：Gpg4win を使う場合、デフォルトは LibrePGP 路線
- **Thunderbird ユーザー**：OS を問わず、内蔵 RNP 経由で LibrePGP 路線
- **ProtonMail ユーザー**：RFC 9580 実装（OpenPGP.js / GopenPGP）
問題が顕在化するのは、片方が新仕様独自の機能（v6 鍵フォーマット、新しい AEAD モード等）を使う場合である。基本的な相互運用性（v4 鍵 + RSA 4096 等）は両者で確保されている。
---
## 3. RFC 9580 と LibrePGP の分岐の経緯
### 3.1 経緯の整理（事実）
OpenPGP は RFC 4880（2007年公開）以降、長らく仕様更新が停滞していた。IETF OpenPGP Working Group は「crypto refresh」プロジェクトとして仕様の現代化を進め、その成果が RFC 9580 として結実した。一方、GnuPG プロジェクトは IETF の方向性に同意せず、独自路線を取った。主要な時系列は以下の通りである[^1][^2][^3]。
- **2007年11月**：RFC 4880 公開（OpenPGP の長らくの基準）
- **2018〜2023年**：IETF OpenPGP WG が「crypto refresh」を進行（複数ドラフトを公開）
- **2023年11月**：GnuPG メイン開発者の Werner Koch 氏が「LibrePGP」を提唱[^1]
- LibrePGP は RFC 4880 を起点とし、より保守的な進化を志向（既存実装との互換性重視）
- GnuPG 2.4.0 は LibrePGP 仕様に準拠した v5 アーティファクトの生成を始めた[^3]。ただし、通常の鍵生成（Ed25519 等）では依然として v4 鍵がデフォルトであることが、本レポートでの実検証（GnuPG 2.4.9 上流純正）により確認されている[^28]
- **2024年7月**：RFC 9580（OpenPGP）公開[^2]
- v6 鍵フォーマットを採用、AEAD（OCB/EAX/GCM）を正式サポート
- X25519、Ed25519 を必須実装アルゴリズムに位置付け
- **2024年9月以降**：Sequoia PGP、Proton AG、OpenPGP.js 等が RFC 9580 サポートを表明・実装[^3]
- **2024年7月以降**：GnuPG 2.5 系がリリースされ、PQC（Kyber 等）対応が組み込まれる。GnuPG 公式 Download ページの分類では 2.5 系が "stable"、2.4 系が "oldstable"[^30]
- **2026年5月**：本レポートの実検証により、GnuPG 2.5.19 でも通常鍵生成のデフォルトは v4 鍵、PQC 鍵生成では「v4 主鍵 + v5 PQC 副鍵」のハイブリッド構造が生成されることを確認[^31]
### 3.2 両仕様の比較（事実）
| 観点 | RFC 9580（OpenPGP） | LibrePGP |
|---|---|---|
| 起点 | RFC 4880 + crypto refresh | RFC 4880 |
| 鍵フォーマット | v6 を新規導入 | v5（PQC 副鍵で生成。通常鍵生成では v4 が GnuPG 2.4.x / 2.5.x のデフォルト[^28][^31]）/ v4（既存互換） |
| 必須アルゴリズム | X25519、Ed25519 | （RFC 4880 ベース、保守的） |
| AEAD モード | OCB / EAX / GCM | OCB（type 20 パケット） |
| 主な推進主体 | IETF OpenPGP WG | GnuPG プロジェクト（Werner Koch） |
| 主な実装 | Sequoia PGP、ProtonMail（OpenPGP.js / GopenPGP）、go-crypto 系 | GnuPG（上流）、Gpg4win、RNP（Thunderbird 内蔵） |
### 3.3 両者の立場と「対立構造」の中立的整理（解釈）
両陣営とも互いに合理的な理由を主張しており、どちらが「正しい」と一概に断定できる状況ではない[^1][^3]。
- **IETF OpenPGP WG（RFC 9580）側の主張**：crypto refresh の成果として、現代の暗号アルゴリズム（AEAD、X25519、Ed25519）を正式に取り込み、20 年来の仕様を更新する必要がある
- **GnuPG（LibrePGP）側の主張**：v6 鍵フォーマット等の変更は既存の鍵管理エコシステムに不必要な負担を強いる。長期安定性と既存実装との互換性を優先すべき
両仕様とも RFC 4880 を共通の祖先とし、Ed25519/X25519 を中心に据える点は一致している[^1]。基本的な相互運用性（v4 鍵 + Ed25519 + Cv25519 等）は両者で確保されており、問題が顕在化するのは新仕様独自の機能（v6 鍵フォーマット、新しい AEAD モード等）を使う場合である。
Sequoia PGP の公開ブログでは、IETF と GnuPG/LibrePGP の分岐の経緯と影響について詳細に論じられている[^3]。さらに別の解説記事「The OpenPGP Schism」（Jason Self、2025年11月）では、「Sequoia で生成した v6 鍵を GnuPG が『不明なバージョン』として拒否する、あるいはその逆、といった非互換事例が報告されている」と指摘されている[^26]。今後この状況がどう推移するか（統合、棲み分け、片方の収斂）は注視が必要である。
---
## 4. FreePG プロジェクトの存在と機能
### 4.1 概要と目的
FreePG プロジェクト[^4]は、GnuPG 上流に対するパッチセットを共同メンテナンスする取り組みである。これは**主要 Linux ディストリビューションを横断する共同イニシアチブ**である。
**プロジェクトの目的**（FreePG 公式サイトより）[^4]：
1. IETF OpenPGP 仕様（RFC 9580）からの乖離を最小化する
2. 互換性のために LibrePGP アーティファクトの読み込みをサポートする
3. アップストリームで未解決のセキュリティ問題を修正する
4. ダウンストリームディストリビューションのメンテナンスニーズに対応する
**注目すべき点**：FreePG は LibrePGP を完全に排除するのではなく、**生成は OpenPGP 標準で行い、読み込みは LibrePGP もサポートする**設計を採用している。これは互換性を最大化しつつ、新規生成物については IETF 標準に準拠させるという実用的なバランス設計である。
### 4.2 仕組み（compliance mode の制御）
FreePG パッチを適用すると、GnuPG のデフォルト compliance mode が「openpgp」に設定される[^4]：
> By default, FreePG-patched GnuPG will only produce OpenPGP-compatible artifacts. To recover the upstream default behaviour, including generation of LibrePGP artifacts, either: supply the `--gnupg` command line flag, add `compliance gnupg` to your `gpg.conf` file.
参考訳：デフォルトでは、FreePG パッチを適用した GnuPG は OpenPGP 互換のアーティファクトのみを生成する。LibrePGP アーティファクトの生成を含むアップストリームのデフォルト動作に戻すには、`--gnupg` コマンドラインフラグを指定するか、`gpg.conf` に `compliance gnupg` を追加する。
**背景**：GnuPG 2.4 以降、デフォルトで GnuPG 独自の AEAD 拡張（「type 20」OCB Encrypted Data Packet）を生成する。この形式は他の OpenPGP 実装でデコードできず、相互運用性の問題を引き起こす[^5]。FreePG パッチを適用すると、デフォルトでは OpenPGP（RFC 9580）互換のアーティファクトのみが生成され、LibrePGP 固有の機能はオプトイン（明示的指定）となる[^4]。
#### 4.2.1 ディストロ環境の `man gpg` での文書化
上記の仕組みは、Ubuntu / Debian の公式オンライン man ページでも、`gpg(1)` の "Compliance options" セクションとして文書化されている[^32]。Compliance options セクションの冒頭は次のように書かれている：
> These options control what GnuPG is compliant to. Only one of these options may be active at a time. If multiple options are given, the last one supersedes all the others. Note that the default setting of this is nearly always the correct one. See the INTEROPERABILITY WITH OTHER OPENPGP PROGRAMS section below before using one of these options.
参考訳：これらのオプションは、GnuPG が何に準拠しているかを制御する。これらのオプションのうち一度にアクティブにできるのは一つだけである。複数のオプションが指定された場合、最後のものが他のすべてを上書きする。**このデフォルト設定は、ほぼ常に正しい設定である**ことに注意されたい。これらのオプションのいずれかを使用する前に、後述の「INTEROPERABILITY WITH OTHER OPENPGP PROGRAMS」のセクションを参照されたい。
そして、`--gnupg` と `--openpgp` の二つのオプションが、それぞれ次のように説明されている：
> --gnupg
> Use standard GnuPG behavior. This is now LibrePGP behavior, which is a different draft protocol that overlaps in some cases with OpenPGP.
参考訳：標準の GnuPG 挙動を使う。これは現在では LibrePGP の挙動であり、OpenPGP と一部重なるが別のドラフトプロトコルである。
> --openpgp
> Set all packet, cipher and digest options to OpenPGP compatible (RFC-9580) behavior. Note that not all of RFC-9580 is implemented by GnuPG. This is the default option, so it is not generally needed, but it may be useful to override a different compliance option in the gpg.conf file.
参考訳：すべてのパケット、暗号、ダイジェストのオプションを OpenPGP 互換（RFC-9580）の挙動に設定する。RFC-9580 のすべてが GnuPG で実装されているわけではないことに注意されたい。**これがデフォルトオプションであり、通常は必要ない**が、`gpg.conf` ファイル中の別の compliance オプションを上書きするのに有用な場合がある。
#### 4.2.2 man ページの記述から確認できる事実
上記の記述からは、以下の事実が確認できる：
1. **「これがデフォルトオプション」と明記**：Ubuntu / Debian の公式 man ページが、当該環境では `--openpgp`（RFC-9580 互換挙動）がデフォルトであると明言している。本レポート 6.2 節での実検証（`gpg --gpgconf-list | grep -i compliance` の出力 `compliance:16:"openpgp:`）と整合する。**なお、上流純正 GnuPG 2.4.9 / 2.5.19 を自前ビルドした環境では、デフォルト compliance mode は `gnupg`（LibrePGP 路線）であった**（脚注 [^29][^31]）。つまり、Ubuntu / Debian 環境のデフォルトと上流純正のデフォルトは異なっている
2. **「上流 GnuPG の挙動は今や LibrePGP」と明記**：`--gnupg` の説明文は、「standard GnuPG behavior」が現在では LibrePGP に等しいという事実関係を率直に文書化している。LibrePGP が OpenPGP と「a different draft protocol」（別のドラフトプロトコル）であることも明示している
3. **RFC-9580 の完全実装ではない**：「not all of RFC-9580 is implemented by GnuPG」と、自身の実装範囲を率直に開示している。FreePG パッチ込み GnuPG が RFC-9580 互換のアーティファクトを生成するとはいえ、それは「RFC 4880 + RFC-9580 で共通する範囲での互換」と理解すべきである
4. **「デフォルト設定は、ほぼ常に正しい」**：Compliance options セクション全体の説明として、ユーザに対して `--gnupg` や `--openpgp` を明示的に指定する必要はほとんどない、デフォルトのままでよい、というメッセージが伝えられている
#### 4.2.3 Kubuntu と Debian で同一の記述
本レポート執筆時点（2026年5月）で Kubuntu 26.04 LTS および Debian 13 (trixie) で `man gpg` を実行した結果、上記の compliance options セクションの記述は完全に一致することが確認された[^32]。これは両ディストロが共通の FreePG パッチセットを採用していることの傍証となる（解釈）。
なお、当該 man ページの記述自体が上流 GnuPG にも含まれるのか、FreePG パッチで追加・変更されたのか、Debian / Ubuntu 独自のパッチで追加・変更されたのかは、本レポートでは未確認である（後者ほど可能性が高いと見られるが、ソースレベルでの確認は今後の課題）。
### 4.3 採用ディストリビューション
公式サイトに記載されている採用ディストリビューションは以下の通り[^4]：
- Arch Linux
- **Debian**
- **Fedora**
- Gentoo（`app-crypt/freepg` という独立パッケージとして配布）
- NixOS
- **Ubuntu**
つまり、調査対象とした主要 Linux ディストリビューション（Debian、Ubuntu、Fedora、Arch）はすべて FreePG パッチを採用していることになる。openSUSE/SUSE は本リストに含まれていないため、独自対応の可能性が高い。
**重要な留意点**：FreePG 公式サイトには以下の記述もある[^4]：
> Note however that downstreams may apply their own patches in addition to FreePG, and/or omit some FreePG patches. Please contact the individual distributors for information about which particular patches they support.
参考訳：ただし、ダウンストリームは FreePG に加えて独自のパッチを適用したり、FreePG の一部のパッチを省略したりする可能性がある。具体的にどのパッチをサポートしているかは、各ディストリビューションに問い合わせてほしい。
### 4.4 プロジェクトメンバーとガバナンス
**プロジェクトメンバーの構成**（FreePG ガバナンスページより）[^6]：
FreePG の初期メンバーには以下の各ディストリビューションの GnuPG パッケージャーが含まれている：
- Andrew Gallagher（Hockeypuck 開発者）
- Daniel Kahn Gillmor（**Debian** GnuPG パッケージャー）
- Jakub Jelen（**Fedora** GnuPG パッケージャー）
- Wiktor Kwapisiewicz（Signstar 開発者）
- Stig Palmquist(NixOS GnuPG パッケージャー)
- David Runge（**Arch** GnuPG パッケージャー、Arch マスターキー保有者の一人）
- Heiko Schäfer（rPGP 開発者）
- Aron Wussler（OpenPGP PQC ドラフト共著者）
**ガバナンス**：FreePG は「rough consensus」方式（IETF プロセスを参照）で意思決定を行う[^6]。これは IETF 流の運営手法を採用していることを意味し、IETF OpenPGP 標準への親和性を象徴している。
**Arch Linux の対応経緯**：Arch Linux は 2024年に gnupg パッケージで「個別パッチを当てる方式」から「FreePG プロジェクトの全パッチを採用する方式」へ移行した[^9]。
### 4.5 含意（解釈）
FreePG の存在は、「IETF（RFC 9580）と GnuPG（LibrePGP）の方向性分岐」に対する、**主要 Linux ディストリビューションのパッケージャー集団による集合的回答**と読める。具体的には：
1. **「事実上の業界標準」としての OpenPGP 互換**：主要 Linux ディストロの GnuPG パッケージはすべて FreePG パッチを通すことで、デフォルトで OpenPGP（RFC 9580）互換のアーティファクトを生成する
2. **GnuPG 上流の独自路線への補正機能**：上流が独自の AEAD/PQC フォーマットを推進する一方、ダウンストリームが集団でこれを抑制している
3. **OSS ガバナンスの興味深い事例**：単一の上流プロジェクトに対して、複数ダウンストリームが連携して標準互換性を確保するという、OSS エコシステムの自治メカニズム
ただし、ユーザー視点では透過的（特別な操作なしにこの恩恵を受ける）であるため、FreePG の存在自体を意識する機会は少ない。本動向は実装レイヤーで進行している重要な取り組みである。
---
## 5. OS・実装別の立場
### 5.1 Linux 主要ディストロ（GnuPG + FreePG パッチ）
**事実**：
主要 Linux ディストロ（Arch、Debian、Fedora、Gentoo、NixOS、Ubuntu）は FreePG パッチを採用しており、デフォルトで OpenPGP（RFC 9580）互換のアーティファクトを生成する[^4]。
ArchWiki の GnuPG ページには以下の記述がある[^10]：
> Arch Linux's position is to prefer compatibility with the OpenPGP standard. To this end the patches from the FreePG project (jointly maintained by package maintainers from several Linux distributions) are applied to the gnupg package.
参考訳：Arch Linux の立場は、OpenPGP 標準との互換性を優先することである。この目的のため、複数の Linux ディストリビューションのパッケージメンテナーが共同で維持する FreePG プロジェクトのパッチが gnupg パッケージに適用されている。
### 5.2 Windows: Gpg4win
**事実**：
Gpg4win（GNU Privacy Guard for Windows）は、Windows 環境の主要な OpenPGP 実装である[^11]。LibrePGP 公式サイト[^12]は Gpg4win について以下のように述べている：
> Since its inception more than 18 years ago Gpg4win is the de-facto standard to use LibrePGP on Windows.
参考訳：18年以上の歴史を持つ Gpg4win は、Windows で LibrePGP を使うためのデファクト標準である。
**開発主体**（Gpg4win 公式 Impressum および GitHub 上の Copyright 表記より一次情報確認済み）[^11][^21]：
- Intevation GmbH（プロジェクト調整、ホスティング担当）
- g10 Code GmbH（暗号コア、GpgOL、GpgEX、GPA 担当）
- KDAB（Kleopatra 開発、過去）
- ドイツ連邦情報セキュリティ庁（BSI）も Copyright に含まれる（2015-2018年分）
g10 Code GmbH の代表は Werner Koch 氏（GnuPG メイン開発者、LibrePGP 提唱者）。Gpg4win の開発主体は GnuPG 上流とほぼ同一であり、開発方針は LibrePGP 路線を踏襲している。
**含意**：Gpg4win は、Linux ディストロが FreePG パッチで補正している方向と**逆方向**、すなわち**上流 GnuPG/LibrePGP の方針をそのまま採用**している。これは Werner Koch 氏が両プロジェクトの中心人物であることから自然な帰結である。
### 5.3 macOS: GPG Suite (GPGTools)
**事実**：
- GPG Suite（GPGTools）は macOS 環境の主要な OpenPGP 実装[^13]
- 内蔵される GPG エンジンは MacGPG（GnuPG ベース）
- LibrePGP 公式サイトの「Software with LibrePGP support」リストに **GPGTools が掲載**されている[^12]
ただし、「LibrePGP support」（LibrePGP をサポート＝読める）という記述と、Gpg4win に対する「LibrePGP のデファクト標準」という記述は意味が異なる点に注意。GPG Suite が新規鍵生成のデフォルトでどちらの仕様を生成するかについては、本調査の範囲では一次情報から明示的に確認できなかった。
**仮説**：MacGPG は上流 GnuPG をベースとしている可能性が高く、その場合は上流の方針（LibrePGP）に追従していると推察される。確定的な判断には MacGPG のソースコードまたは GPGTools 公式の方針表明の確認が必要。
### 5.4 Thunderbird: RNP 内蔵
**事実（重要）**：
Mozilla Thunderbird の OpenPGP 機能は、**RNP（Ribose 開発の C++ 実装）を内蔵**している[^7]。RNP は LibrePGP 公式サイトの公式サポーターとして掲載されており[^12]、2024年に LibrePGP の正式サポートを発表している[^8]。
RNP 公式サイトの記述[^8]：
> RNP is excited to announce our support for LibrePGP, a new specification of the OpenPGP encryption standard that builds on the lessons learned from 20 years of experience with GnuPG.
参考訳：RNP は LibrePGP のサポートを発表できることを嬉しく思う。LibrePGP は、GnuPG の 20 年の経験から得られた教訓に基づいて構築された、OpenPGP 暗号化標準の新しい仕様である。
**含意**：Thunderbird ユーザーは、OS（Windows/macOS/Linux）を問わず、デフォルトで **LibrePGP 側の実装**を使用していることになる。Thunderbird のシェア（メールクライアントとして広く利用されている）を考えると、これは重要な事実である。
### 5.5 ProtonMail: OpenPGP.js / GopenPGP
**事実**：
ProtonMail は二つの OpenPGP ライブラリを開発・維持している。
- **OpenPGP.js**（JavaScript 実装、Web メール用）：README に「It implements RFC 9580 (superseding RFC 4880 and RFC 4880bis)」と明記されている[^14]
- **GopenPGP**（Go 実装、サーバー用）：v3 で RFC 9580 プロファイル（curve25519 v6 鍵生成、Argon2、AEAD AES-256/OCB モード）を提供[^15]
GopenPGP のコメントでは「Note that RSA keys should not be generated anymore according to RFC 9580」とまで記述されており[^15]、Proton 側の方針が RFC 9580 路線に明確に立っていることが確認できる。
**含意**：ProtonMail Web メールおよびサーバーサイドの暗号化処理は、RFC 9580 実装に基づいている。Proton AG は LibrePGP 公式サイトの「Software with LibrePGP support」リストには掲載されていない[^12]。
### 5.6 Sequoia PGP（Fedora の sq 等）
**事実**：
- Sequoia PGP は Rust ベースの新世代 OpenPGP 実装で、RFC 9580 を実装している
- Fedora は最新ドキュメントで `sq verify`（Sequoia PGP の CLI ツール）を `gpg` と並行して紹介している[^22]
- Sequoia は 2025年11月に PQC 対応のプレビュー版（sequoia-sq 1.4.0-pqc.1）を公開[^23]
Fedora の対応は、GnuPG だけに依存せず Sequoia PGP も並行して採用するという形で **OpenPGP 実装の多様化**を進めている事例である。
### 5.7 OS / 主要ソフトウェア別の実装系統まとめ（事実として確認できる構造）
| 利用環境 | 主要実装 | 拠って立つ仕様 | 確度 |
|---|---|---|---|
| Linux 主要ディストロ | GnuPG + FreePG パッチ | OpenPGP（RFC 9580）互換生成、LibrePGP 読み込み可 | ◯ 一次情報確認済み |
| Windows | Gpg4win（上流 GnuPG ベース） | LibrePGP のデファクト標準（公式自認） | ◯ 一次情報確認済み |
| Thunderbird（クロスプラットフォーム） | RNP 内蔵 | LibrePGP（公式サポーター） | ◯ 一次情報確認済み |
| macOS | GPG Suite / MacGPG | LibrePGP 互換（公式サポーターリスト掲載）。デフォルト挙動は未確認 | △ 部分確認 |
| ProtonMail（Web メール / サーバー） | OpenPGP.js / GopenPGP | RFC 9580 路線 | ◯ 一次情報確認済み |
| その他 RFC 9580 専用実装 | Sequoia PGP（→ Fedora の sq 等） | RFC 9580 路線 | ◯ 確認済み |
**含意（解釈）**：
OS 環境やソフトウェアによって、デフォルトで生成される暗号アーティファクトの形式が異なる可能性がある。具体的には：
- Linux ユーザー（FreePG パッチ適用環境）が暗号化したファイル → デフォルトは OpenPGP（RFC 9580）互換
- Windows の Gpg4win ユーザーが暗号化したファイル → デフォルトは LibrePGP
- Thunderbird ユーザー（OS問わず）が送受信する暗号化メール → RNP 経由で LibrePGP 側
- ProtonMail ユーザーが送受信する暗号化メール → OpenPGP.js / GopenPGP 経由で RFC 9580 側
ただし、両仕様とも RFC 4880 を共通の祖先とし、基本的な相互運用性は確保されている。問題が顕在化するのは、片方が新仕様独自の機能（v6 鍵フォーマット、新しい AEAD モード等）を使う場合である。
---
## 6. 実検証結果
### 6.1 Debian 13 (trixie) の Ed25519 採用
**Debian 13 (trixie) 環境での実検証（2026年5月）**[^16]：
`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年間）有効
- 命名規則移行のため、`.pgp` と `.gpg` の両方の名前で同じ鍵が配置されている
**比較**：Kubuntu 26.04 LTS の archive keyring を同様に調査すると、3 つの archive key（2012年 × 2、2018年 × 1）はいずれも **RSA 4096**、有効期限は設定されていない（永続有効）[^17]。
| 項目 | 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）の機会に新規鍵をモダンなアルゴリズムで発行した、と読める。
**含意**：Debian 13 の Ed25519 採用は、本レポートの実装エコシステム文脈においても重要である。Debian の archive 署名鍵が Ed25519（RFC 9580 必須実装の楕円曲線署名アルゴリズム）に切り替わったということは、**Debian プロジェクトとしての OpenPGP 標準路線への明確な追従**を意味する。これは FreePG パッチ採用と方向性を共有する動きである。
### 6.2 FreePG パッチの効果（Kubuntu 26.04 LTS）
ArchWiki の GnuPG ページには、以下の警告が記載されている[^5]：
> When using --full-gen-key the generated key will advertise an AEAD mechanism, which is not understood by other OpenPGP implementations.
参考訳：`--full-gen-key` を使うと、生成された鍵は AEAD 機構を宣言する。これは他の OpenPGP 実装では理解されない。
つまり「FreePG パッチを当てた GnuPG であっても、`--full-gen-key` を使うと OCB ベースの AEAD が依然としてセットされる」とされている。
**実検証**：Arch Linux とは異なるが、 Kubuntu 26.04 LTS / GnuPG 2.4.8 環境で `gpg --full-generate-key --expert` で新規鍵を生成し、setpref による preferences 変更を行わない状態で `gpg --edit-key <FINGERPRINT> showpref` を実行した結果、以下が観察された[^18]：
```
Cipher: AES256, AES192, AES, 3DES
AEAD:
Digest: SHA512, SHA384, SHA256, SHA224, SHA1
Compression: ZLIB, BZIP2, ZIP, Uncompressed
Features: MDC, Keyserver no-modify
```
**観察された事実**：
- AEAD: 行が空
- Features: 行に "AEAD" が含まれない（"MDC, Keyserver no-modify" のみ）
これは ArchWiki の警告と異なる挙動である。原因を確定するため、Kubuntu 26.04 の gnupg パッケージのソースを `apt source gnupg` で取得し、`debian/patches/series` を確認したところ、FreePG プロジェクトのパッチが多数含まれていることが判明した[^19]：
```
freepg/0011-el-gamal-default-to-3072-bits.patch
freepg/0012-gpg-default-digest-algorithm-SHA512.patch
freepg/0013-gpg-Prefer-SHA-512-and-SHA-384-in-personal-digest.patch
freepg/0018-Avoid-simple-memory-dumps-via-ptrace.patch
freepg/0019-Disallow-compressed-signatures-and-certificates.patch
freepg/0021-gpg-Sync-compliance-mode-cleanup-with-master.patch
freepg/0022-gpg-emit-RSA-pubkey-algorithm-when-in-compatibility-.patch
freepg/0023-gpg-Reintroduce-openpgp-as-distinct-from-rfc4880.patch
freepg/0024-gpg-Emit-LibrePGP-material-only-in-compliance-gnupg.patch
freepg/0025-gpg-gpgconf-list-report-actual-compliance-mode.patch
freepg/0026-gpg-Default-to-compliance-openpgp.patch
（その他、計 22 個の FreePG パッチ）
```
**特に決定的なパッチ 2 つ**：
| パッチ番号 | 効果 |
|---|---|
| **0026: Default to compliance openpgp** | GnuPG のデフォルト compliance mode を `openpgp` に設定 |
| **0024: Emit LibrePGP material only in compliance gnupg** | LibrePGP 固有の機構（OCB AEAD 等）は `--compliance=gnupg` モードでのみ生成 |
この 2 つのパッチが組み合わさることで、デフォルト挙動として以下が実現される：
1. デフォルトの compliance は `openpgp`（パッチ 0026）
2. その状態では LibrePGP material（OCB AEAD 等）は生成されない（パッチ 0024）
3. `--full-generate-key` のコードパスでも、これらが適用される
**注目すべき他のパッチ**：
| パッチ | セキュリティ強化・標準準拠の方向性 |
|---|---|
| 0011: El Gamal デフォルトを 3072 bit | El Gamal の鍵長を強化 |
| 0012: デフォルトハッシュを SHA512 | ハッシュアルゴリズムを強化 |
| 0013: SHA-512/SHA-384 を優先 | personal-digest preferences の改善 |
| 0018: ptrace 経由のメモリダンプ回避 | プロセスメモリ保護 |
| 0023: openpgp を rfc4880 から分離 | compliance mode の概念整理 |
| 0025: gpgconf で実 compliance mode を報告 | 透明性の向上 |
これらは「上流が受け入れない、あるいは対応が遅いセキュリティ強化や標準準拠の改善を、ダウンストリームが集合的に維持している」という FreePG プロジェクトの存在意義の典型例である。
**含意（解釈）**：
(1) Kubuntu 26.04 における AEAD 抑制は、**FreePG プロジェクトのパッチによるもの**であることがソースの直接確認により裏付けられた。具体的には、Kubuntu 26.04 LTS の gnupg ソースパッケージに含まれるパッチ 0026（compliance mode のデフォルトを `openpgp` に設定）と 0024（LibrePGP material は `--compliance=gnupg` モードでのみ生成）の組み合わせが、`--full-generate-key` のコードパスでも有効に機能していることが観察された。
(2) FreePG プロジェクトのパッチ 0024/0026 を採用している環境では、`--full-gen-key` を含むあらゆる鍵生成コードパスで compliance mode が効くように設計されていると考えられる。これは「上流の独自路線をダウンストリームが集合的に補正する」という FreePG プロジェクトの存在意義の典型例である。
(3) ただし、ArchWiki の警告（「`--full-gen-key` を使うと AEAD: OCB が依然としてセットされる」）が、現在の Arch Linux 環境で依然として正確であるかどうかは、本実検証では確認していない（実検証は Kubuntu 26.04 LTS で行ったものであり、Arch Linux では未検証）。FreePG 公式サイトには「ダウンストリームは FreePG に加えて独自のパッチを適用したり、FreePG の一部のパッチを省略したりする可能性がある」（4.3 節で引用）との記述があり、Arch Linux のパッチ採用状況によっては挙動が異なる可能性がある。以下の三つの可能性が並立する：
- **可能性 A**：Arch Linux も Ubuntu と同じくパッチ 0024/0026 を採用しており、ArchWiki の警告は実態と乖離している（情報が古い）
- **可能性 B**：Arch Linux はパッチ 0024/0026 を省略しており、ArchWiki の警告は Arch 環境で依然として正確である
- **可能性 C**：Arch Linux のパッチセットは Ubuntu と異なる組み合わせであり、別の挙動を示す
どれが実態かは Arch Linux 環境での実検証を行わないと判別できない。本レポートの実検証で確実に言えるのは、「**Kubuntu 26.04 LTS / GnuPG 2.4.8 環境では、ArchWiki の記載と異なる挙動が観察された**」という限定的な事実のみである。
(4) なお、上流純正 GnuPG 2.4.9（FreePG パッチなし、自前ビルド）での実検証では、ArchWiki の警告通り **AEAD: OCB がデフォルトでセット**されることが確認された[^29]。これにより、FreePG パッチが具体的に何を変えているかが、両側からの実検証で明確になった：
| 観察項目 | 上流純正 GnuPG 2.4.9 | FreePG パッチ込み GnuPG 2.4.8（Kubuntu 26.04 LTS） |
|---|---|---|
| デフォルト compliance | `gnupg` | `openpgp`（パッチ 0026 の効果） |
| 鍵フォーマット（通常鍵生成） | v4 | v4 |
| 主鍵アルゴリズム（デフォルト） | algo 22（EdDSA Legacy）| algo 22（EdDSA Legacy）|
| AEAD preference | **OCB が含まれる** | **空（パッチ 0024 の効果）** |
| Features の AEAD | あり | なし |
つまり FreePG パッチは、**「鍵フォーマットそのもの（v4）は変えず、AEAD の preference だけを抑制する」**という精緻な振る舞いをしている。この差分が、相互運用性の観点では重要である：v4 鍵は両陣営で読めるが、AEAD: OCB の preference を持つ v4 鍵は、OCB 非対応の OpenPGP 実装と暗号化メッセージのやり取りで問題を生じる可能性がある。
(5) ユーザー視点では、Ubuntu/Debian/Fedora/Arch/Gentoo/NixOS 等の主要 Linux ディストロを使う限り、デフォルトで OpenPGP（RFC 9580 系）互換のアーティファクトが生成される（FreePG 公式サイトおよび ArchWiki の記述による）。これは透明（ユーザーは特に意識しない）であるが、その背後には FreePG プロジェクトの能動的な活動がある。ただし、`--full-gen-key` 等の特定のコードパスでの細部の挙動は、各ディストロのパッチ採用状況によって差異が生じる可能性があり、相互運用性が問題になる場面では実機での確認が望ましい。
### 6.3 Debian における gnupg24 ITP の動きと顛末
**事実（時系列）**：
Debian では、上流 GnuPG（LibrePGP 互換）をそのまま提供する gnupg24 パッケージの ITP（Intent To Package）が 2025年に提出されたが、**2025年2月に取り下げ**となった[^20]。
- 2025年1月14日：Simon Josefsson 氏が gnupg24（LibrePGP 互換実装）の ITP を提出
- 2025年2月：Debian Release Team が「3つの実装を trixie に入れることは望まない」と表明
- 2025年2月23日：Simon Josefsson 氏自身が ITP をクローズ
クローズ時の Simon Josefsson 氏の声明（要旨、原文より引用）[^20]：
> 1) GnuPG 2.4.x is not uploaded to sid/trixie and that this lowers security for users to the GnuPG 2.2 era, and 2) that the Debian GnuPG team is patching GnuPG to deviate from what upstream desire in a deep way. ... it seems to me that there are fundamental different priorities in play here (pushing the pro-OpenPGP-anti-GnuPG agenda)
参考訳：1) GnuPG 2.4.x が sid/trixie にアップロードされておらず、これがユーザーのセキュリティを GnuPG 2.2 時代の水準に下げている、2) Debian GnuPG チームが上流の希望から深く乖離する形で GnuPG にパッチを当てている。…ここには根本的に異なる優先順位（pro-OpenPGP・anti-GnuPG な agenda の推進）が働いていると思われる。
これに対する Debian GnuPG パッケージャー Daniel Kahn Gillmor 氏（FreePG メンバー）の立場（同 ML 上の発言から）[^20]：
> all the relevant 2.2 patches in the FreePG repository are already in Debian's unstable branch, and in most cases we have been shipping them for years to address user needs that upstream GnuPG declines to acknowledge or support. ... In the ideal case, of course, we'd eliminate all our divergence from upstream, but that would depend on upstream being interested in working with the use cases and concerns that our users have.
参考訳：FreePG リポジトリの該当する 2.2 のパッチはすべて Debian unstable ブランチに既に入っており、多くの場合は何年も前から、上流 GnuPG が認めようとも支援しようともしないユーザーのニーズに対応するため出荷してきた。…理想的には我々は上流からの乖離をすべて取り除きたいが、それには上流が我々のユーザーの使い方や懸念に応じることに関心を持つかどうかにかかっている。
**留意（中立性の観点から）**：これら両者の立場は、それぞれの観点から内的整合性のある主張である：
- **Josefsson 氏の立場**：上流 GnuPG（LibrePGP 互換）を選択肢として用意したい。Debian の現状は上流から乖離し過ぎている
- **Gillmor 氏ら FreePG 側の立場**：上流が OpenPGP 互換性のためのパッチを受け入れないため、ユーザーの相互運用性ニーズを満たすために独自パッチを維持せざるを得ない
両者とも「理想は上流との収斂」と表明しており、対立は技術的選好というより、現状の解決策に関する見解の相違である。
**補足**：実検証および公開情報からは、Kubuntu 26.04 LTS は GnuPG 2.4.8、Debian 13 (trixie) は GnuPG 2.4.7 を採用していることが確認された[^17][^16]。前述の Josefsson 氏の発言（2025年初）「Debian sid/trixie に GnuPG 2.4.x がアップロードされていない」という指摘は、その後 GnuPG 2.4.x が main 入りしたことを示唆する。Debian 13 trixie のリリース（2025年8月）に間に合わせる形で 2.4 系への移行が進んだと推察される（解釈）。
### 6.4 GnuPG 2.5.19 における鍵フォーマットの実検証
LibrePGP 路線の実装が「v5 鍵」をどのような条件下で生成するのかを明らかにするため、GnuPG 2.5.19 を上流ソースから自前ビルドして実検証した。GnuPG 2.5.19 は GnuPG プロジェクトの公式 Download ページで "(stable)" として分類される現行版であり[^30]、PQC（Kyber 等）対応が組み込まれている。
#### 6.4.1 検証環境の構築
- **GnuPG 2.5.19**：上流ソース（gnupg-2.5.19.tar.bz2）を speedo（`build-aux/speedo.mk native`）でビルド
- **インストール先**：`$HOME/local/gnupg-2.5.19`（独立した prefix。システム GnuPG とは衝突しない）
- **依存ライブラリ**：speedo が自動取得・ビルド（libgcrypt 1.12.2 含む）
- **検証用 GNUPGHOME**：`$(mktemp -d)` で都度作成、検証後に削除
- **pinentry**：システムの pinentry を `$GNUPGHOME/gpg-agent.conf` 経由で借用（速度のため、自前ビルドはしていない）
- **ホスト環境**：Kubuntu 26.04 LTS
確認できた仕様：
```
gpg (GnuPG) 2.5.19
libgcrypt 1.12.2
Pubkey: RSA, Kyber, ELG, DSA, ECDH, ECDSA, EDDSA
```
`Kyber` が Pubkey 一覧に含まれており、PQC 対応が有効なビルドであることが確認できる。
#### 6.4.2 通常鍵生成の挙動
PQC を選ばない通常鍵生成（`gpg --batch --quick-generate-key ... default default never`）を実行した結果[^31]：
| 観察項目 | 結果 |
|---|---|
| デフォルト compliance mode | `gnupg`（LibrePGP 路線、2.4.9 と同じ）|
| 主鍵 version | **v4** |
| 主鍵 algo | 22（EdDSA Legacy）|
| 副鍵 version | **v4** |
| 副鍵 algo | 18（ECDH/Cv25519）|
| AEAD preference | OCB |
**観察**：GnuPG 2.5.19 でも、通常鍵生成のデフォルトは v4 鍵である。これは GnuPG 2.4.9 上流純正での観察（6.2 節および脚注 [^29]）と完全に同一であり、「LibrePGP 路線でも、通常の鍵生成では v4 鍵フォーマットが維持されている」という事実が、stable と oldstable の両系列で確認できた。
#### 6.4.3 PQC 鍵生成の挙動
`gpg --full-generate-key --expert` の対話メニューで「(16) ECC と Kyber」を選択し、「(1) Kyber 768 (bp256)」（Brainpool P-256 で署名 + Kyber 768 で鍵共有のハイブリッド構成）を選んで鍵を生成した。生成された鍵を `gpg --export | gpg --list-packets` で確認した結果[^31]：
```
:public key packet:
version 4, algo 19, created 1778331942, expires 0
:public sub key packet:
version 5, algo 8, created 1778331942, expires 0, pkbytes 1265
```
| パケット | version | algo | サイズ | 意味 |
|---|---|---|---|---|
| 主鍵 | **v4** | 19 | 標準 | ECDSA、Brainpool P-256（署名用） |
| 主鍵の自己署名 | v4 | - | - | sigclass 0x13（positive certification） |
| **PQC 副鍵** | **v5** | **8** | **1265 bytes** | **Kyber 768、暗号化用** |
| 副鍵バインディング署名 | v4 | - | - | sigclass 0x18 |
**観察された主要な事実**：
(1) **主鍵は v4 のまま、PQC 副鍵のみが v5** という、ハイブリッド構造が観察された。鍵全体を v5 に切り替えるのではなく、「**従来の v4 主鍵（既存の Web of Trust と互換）に、PQC 専用の v5 副鍵を追加する**」という設計である。
(2) **副鍵バインディング署名は v4 で行われている**。つまり、v5 副鍵を v4 主鍵に紐付ける署名そのものは v4 形式を維持している。これにより、v4 鍵フォーマットを理解する OpenPGP 実装からも、この鍵は「v4 主鍵」として認識可能となる。
(3) **Kyber 768 公開鍵は 1265 バイト**と、従来の暗号アルゴリズム（Ed25519: 32 バイト、RSA 4096: 約 512 バイト）と比較して 2 桁大きい。この鍵長の大きさが、v5 鍵フォーマットを必要とした技術的理由の一つとして推察される（仮説：v4 鍵フォーマットの鍵長フィールドでは収まらない可能性）。
(4) **algo 8 の意味**：従来の OpenPGP（RFC 4880、RFC 9580）では algo 8 は予約番号または別用途に割り当てられていたが、LibrePGP の PQC 実装では Kyber 768 を意味するようである。これは LibrePGP 独自の algo 番号割当である可能性が高く（仮説）、RFC 9580 系の PQC 草案で予定される algo 番号とは異なる可能性がある。
#### 6.4.4 含意（解釈）
**LibrePGP 路線の設計思想の体現**：
LibrePGP の設計思想「長期安定性と既存実装との互換性を重視」が、PQC 鍵の構造レベルで具体的に現れている。鍵全体を新しいフォーマット（v5/v6）に切り替えれば既存の Web of Trust が崩れるが、「主鍵は v4 のまま、PQC 副鍵だけ v5」というハイブリッド設計によって、Web of Trust の連続性を保ちつつ PQC 機能を追加できる。
**RFC 9580 / Sequoia 路線との対比**：
Sequoia PGP では `--profile rfc9580` を指定すると鍵全体が v6 鍵フォーマットで生成される（5.6 節および 7.4.2 節参照）。これは「鍵全体をモダン化する」アプローチであり、既存の Web of Trust とは互換性を持たない。Jason Self 氏が指摘するとおり、「v6 鍵に移行すると、既存の鍵に付いていた他人からの署名がすべて失われる」[^26]という影響がある。
両陣営の設計思想の違いがここに表れている：
| 観点 | LibrePGP 路線（GnuPG）| RFC 9580 / Sequoia 路線 |
|---|---|---|
| 既存 Web of Trust の継続性 | 維持（主鍵を v4 のまま保つ）| 維持しない（v6 鍵への移行で署名喪失）|
| 新機能（PQC）の追加方法 | 副鍵として追加（v5 副鍵）| 鍵全体を新フォーマットに（v6 鍵全体）|
| 互換性の優先 | 既存基盤との互換性 | プロトコル設計の整合性 |
**Jason Self 氏の記事の精緻化**：
Jason Self 氏の記事[^26]は「GnuPG, following the LibrePGP spec, creates a Version 5 (v5) **key**」と記述しているが、本検証で観察された構造はより精緻には「**主鍵は v4、PQC 副鍵のみが v5** のハイブリッド」である。「v5 key」という表現は、PQC 副鍵単体を指したと読むのが正確である。同記事は GnuPG 2.5.13 での観察に基づくが、本レポートの 2.5.19 での観察結果と整合する。
---
## 7. ユーザーへの影響
### 7.1 前提：AEAD と OCB について（基礎用語）
本章の議論には「AEAD」「OCB」といった暗号技術用語が頻出する。これらは LibrePGP / RFC 9580 分岐における主要な争点の一つであるため、議論に入る前に基礎を整理する。
#### 7.1.1 AEAD とは何か
**AEAD（Authenticated Encryption with Associated Data、認証付き暗号化）** は、暗号化と改ざん検出を**同時に**行う暗号方式の総称である。
OpenPGP の従来の暗号化（RFC 4880 時代）は、二段構えだった：
> 平文 → AES などで暗号化 → 暗号文
>
> 平文のハッシュ → MDC（Modification Detection Code）
「**MDC**（改ざん検出コード）」というハッシュ値を末尾に付け、復号時にハッシュを再計算して一致を確認する方式である。これは「暗号化」と「改ざん検出」を**別々の処理で**行う形である。本レポートの実検証で観察された `Features: MDC, Keyserver no-modify` の「MDC」が、まさにこれである。
AEAD は、この二段構えを**一体化**する。
> 平文 → AEAD で暗号化 → 暗号文 + 認証タグ（一体化）
利点は以下の通り：
1. **処理が一回で済む**：暗号化と改ざん検出を別々に走らせるより速い
2. **ハードウェア支援が効く**：現代の CPU の AES-NI のような命令により、AEAD 処理がさらに加速される
3. **特定の攻撃に構造的に強い**：暗号文を部分的に改ざんしてハッシュ計算をすり抜ける、といった攻撃を防ぐ
ここで注意すべきは、**AEAD は「枠組み」であり、具体的なアルゴリズムの名前ではない**ということである。AEAD のカテゴリには以下のような複数の具体的アルゴリズムがある：
| アルゴリズム | 名前の由来 | 採用例 |
|---|---|---|
| **OCB** | Offset Codebook Mode | LibrePGP、RFC 9580、IETF QUIC |
| **GCM** | Galois/Counter Mode | TLS 1.2/1.3 で広く使用 |
| **EAX** | Encrypt-then-Authenticate-then-Translate | RFC 9580 でも採用 |
| **ChaCha20-Poly1305** | アルゴリズム名そのまま | TLS 1.3、WireGuard、SSH |
つまり、本レポートで頻出する「**AEAD: OCB**」という表記は「**AEAD という枠組みの中で、OCB という具体的なやり方を使う**」という意味である。
#### 7.1.2 OCB とは何か
**OCB（Offset Codebook Mode）** は、Phillip Rogaway が 2001 年頃に発表した AEAD アルゴリズムである。技術的特徴：
- **AES などのブロック暗号を 1 回だけ通す**：内部で AES を二回呼ぶ GCM などと比べ、計算量が約半分。**最も高速な AEAD の一つ**である
- **並列化が容易**：ブロックごとに独立して処理できるため、マルチコア CPU で性能が出る
- **特許問題が長らく障害だった**：Rogaway が特許を取得していたため、商用利用に懸念があった。**2021 年 2 月に Rogaway 自身が IETF CFRG メーリングリストで特許放棄を確認**し、ようやく自由に使えるようになった
OpenPGP コミュニティが OCB を採用した経緯は、この特許パブリックドメイン化が大きい。GnuPG の Werner Koch 氏も RNP（Thunderbird 内蔵）も「最高性能の AEAD を OpenPGP に取り込みたい」という同じ動機で OCB を選んだ。
#### 7.1.3 鍵に書かれる「AEAD: OCB」の意味
実検証で観察された `AEAD: OCB` という preference は、鍵の所有者が「**私宛に暗号化するときは、OCB という AEAD で暗号化していいですよ**」と他人に**宣言**している印である。
具体的な動作：
1. Alice の鍵に `AEAD: OCB` と書かれている
2. Bob が Alice 宛に暗号化メッセージを送りたい
3. Bob の OpenPGP 実装は Alice の鍵を見て、「Alice は OCB をサポートする」と判断
4. **Bob の実装が OCB をサポートしていれば** OCB で暗号化、サポートしていなければフォールバック
ここに次節以降の互換性問題の核心がある。
#### 7.1.4 互換性問題の正体（中身は同じ、箱が違う）
OpenPGP / LibrePGP 分岐の前後で、OCB の**包み方（パケット形式）**が変わってしまった。
| 規格 | OCB の格納方法 |
|---|---|
| LibrePGP（GnuPG 2.4 以降の上流） | **type 20 パケット**（独自） |
| RFC 9580（IETF） | type 18/19/20 系を整理した新パケット形式（鍵ごとに用途が違う） |
両者とも**中身は OCB**だが、「**OCB をどういう箱に入れて運ぶか**」が違うため、相手の実装が違う形式を理解できないと復号できない、という事態が起きうる。
比喩で言えば、**OCB は荷物の中身（高性能な暗号化）、パケット形式は荷物の梱包箱（運び方）**である。LibrePGP と RFC 9580 は、**同じ高品質な品物を別の梱包箱で配送する宅配業者**のようなものだ。中身（OCB）は同じだが、A 社の梱包箱を受け取った B 社の倉庫が「うちの仕分け機械はこの形の箱を扱えません」と返送してしまう、というような状況である。
しかも、**FreePG パッチが何をしているかも、この比喩で理解できる**。「**配達伝票（preference）に高級品配送可能と書かない**」ことで、相手の業者がそもそも高級品（OCB）を送ってこないようにする、という上流側の事故防止策である。中身を運ぶ能力（読み込み）は維持しつつ、不確実な配送経路（生成）を避ける、という設計判断と読める。
これが、4.1 節で触れた「FreePG は LibrePGP を完全に排除するのではなく、**生成は OpenPGP 標準で行い、読み込みは LibrePGP もサポートする**設計」の具体的中身である。
### 7.2 透過的な影響：ユーザーは通常意識しない
主要 Linux ディストロのユーザー（Debian/Ubuntu/Fedora/Arch/Gentoo/NixOS）は、特に何もしなくても **OpenPGP（RFC 9580）互換のアーティファクト**をデフォルトで生成している。これは FreePG プロジェクトのパッチによる「透明な恩恵」であるが、ユーザーは通常その存在を意識しない。
逆に Windows ユーザー（Gpg4win）、Thunderbird ユーザー（RNP 内蔵）は、デフォルトで **LibrePGP 路線**の実装を使っている。これも特別な操作なしに、実装が選択している立場の結果である。
### 7.3 顕在化する影響：互換性問題
「互換性が失われる／失われない」という問いは、実は単一の答えを持たない。**何の互換性か**によって答えが変わるため、ここでは三つの軸に分けて整理する。本レポートの実検証データ（6.2 節、6.4 節、脚注 [^28][^29][^31]）に基づく。
#### 7.3.1 軸 1：鍵そのもの（公開鍵のインポート・エクスポート）
**結論：完全に互換**。
通常鍵生成では、本レポートの実検証で確認した三つの環境はいずれも **v4 鍵**を生成した：
| 環境 | 通常鍵生成のフォーマット |
|---|---|
| Kubuntu 26.04 LTS / FreePG パッチ込み GnuPG 2.4.8 | v4 |
| 上流純正 GnuPG 2.4.9（FreePG パッチなし、自前ビルド）| v4 |
| 上流純正 GnuPG 2.5.19（PQC 対応 stable、FreePG パッチなし、自前ビルド）| v4 |
v4 鍵はすべての OpenPGP 実装で読めるフォーマットであるため、
- 上流純正 GnuPG で生成した鍵を、Linux ディストロ（FreePG パッチ込み）GnuPG にインポート → ✅ 可能
- その逆 → ✅ 可能
- Sequoia PGP（`sq` のデフォルト profile も v4） にインポート → ✅ 可能
- ProtonMail にアップロード → ✅ 可能
つまり、**「純正 GnuPG とディストロ GnuPG で互換性が失われている」というような状況にはない**。
#### 7.3.2 軸 2：暗号化アーティファクト（暗号化メッセージ・署名）
**結論：基本的に互換、ただし AEAD preference の差が伏在**。
実検証で観察された preference の差：
| 環境 | AEAD preference | Features の AEAD |
|---|---|---|
| Kubuntu 26.04 LTS / FreePG パッチ込み GnuPG 2.4.8 | 空 | なし |
| 上流純正 GnuPG 2.4.9 | **OCB あり** | あり |
| 上流純正 GnuPG 2.5.19 | **OCB あり** | あり |
この差が暗号化アーティファクトの相互運用性に与える影響：
**シナリオ（a）：FreePG パッチ込み GnuPG ユーザの鍵を、別の OpenPGP ユーザが受け取って暗号化する**
- 受信者の鍵に AEAD preference がない
- 送信者は MDC（Modification Detection Code）方式で暗号化（古い方式、すべての OpenPGP 実装が読める）
- → 完全互換。問題なし
**シナリオ（b）：上流純正 GnuPG ユーザの鍵を、別の GnuPG 系ユーザが受け取って暗号化する**
- 受信者の鍵に「AEAD: OCB をサポート」と記載
- 送信者の GnuPG は LibrePGP の type 20 OCB パケットで暗号化する可能性が高い
- 受信者の GnuPG（純正でも FreePG パッチ込みでも）は type 20 OCB を読める（FreePG パッチは生成は抑制するが読み込みはサポートする設計、4.1 節を参照）
- → **GnuPG 系どうしであれば完全互換**
**シナリオ（c）：上流純正 GnuPG ユーザの鍵宛に、Sequoia PGP や ProtonMail（RFC 9580 専用実装）が暗号化する**
- 受信者の鍵に「AEAD: OCB をサポート」と記載
- ただし、Sequoia や ProtonMail は LibrePGP の type 20 OCB を生成しない設計
- 送信者は AEAD を使わず MDC 方式にフォールバックするか、RFC 9580 の AEAD（パケット番号・モードが異なる）で暗号化する
- フォールバックすれば → 互換性は確保される
- RFC 9580 の AEAD で暗号化したものを受信者の上流純正 GnuPG が読めるか → **未検証、要注意**
つまり、**GnuPG 系どうしでは完全互換だが、Sequoia / ProtonMail と GnuPG 系の間に AEAD: OCB を preference に持つ鍵が存在すると、相互運用上の不確実性が生じる**。
#### 7.3.3 軸 3：PQC 鍵を使う場合
**結論：互換性が失われる可能性が高い**。
本レポートの 6.4 節で実検証したとおり、LibrePGP 路線では「v4 主鍵 + v5 PQC 副鍵（algo 8 = Kyber 768、pkbytes 1265）」のハイブリッド構造で PQC 鍵が生成される。一方、RFC 9580 / Sequoia 路線の PQC 草案では、algo 番号や鍵フォーマットが異なる可能性が高い（仮説）。
具体的なリスク：
- **LibrePGP 路線で生成した PQC 副鍵**を、RFC 9580 / Sequoia 路線の PQC 対応実装で使えるか → 未検証、おそらく不可
- **RFC 9580 / Sequoia 路線で生成した PQC 鍵**を、LibrePGP 路線（GnuPG 2.5.x）で使えるか → 未検証、おそらく不可
ただし、**主鍵自体は v4 のまま**なので、PQC を使わない通常運用（既存の Web of Trust、署名検証、非 PQC 暗号化等）には影響しない。
Jason Self 氏の記事[^26]の表現を借りれば、PQC 移行を急ぐ場合、ユーザは「**両陣営に対応できる二つの PQC 副鍵を持つ**」という非対称な選択肢に直面する可能性がある。LibrePGP 路線で PQC 副鍵を追加し、別途 RFC 9580 路線でも PQC 副鍵を追加する、という二重管理である。
#### 7.3.4 本稿執筆者としての結論
本レポートが伝えるべき要点は次のとおりである：
1. **今すぐの実害はほとんどない**：GnuPG 系どうしの通常運用では、互換性は失われていない。Linux ディストロのユーザも、Windows の Gpg4win ユーザも、ほぼ意識せずに今までどおり使える
2. **不確実性が伏在する場面は限定的**：上流純正 GnuPG 由来の鍵 + Sequoia / ProtonMail という組み合わせで、AEAD preference 経由の不確実性が生じうる。ただしフォールバックで多くの場合は救われる
3. **PQC 移行の局面では分岐が顕在化する**：将来 PQC 鍵を使い始める段階で、自身のツールチェーンと通信相手のツールチェーンの両陣営整合性を意識する必要が出てくる。今のうちから「自身がどちら側にいるか」を把握しておくと、移行時に慌てずに済む
OpenPGP/LibrePGP の分岐は、本レポートの実検証データに照らせば、**本稿執筆時点(2026年5月)のユーザにとっての実害は限定的**である。むしろ重要なのは、来たる PQC 移行の局面で混乱しないよう、現状を正確に把握しておくこと、と整理できる。
##### FreePG パッチの設計判断についての追加考察
7.1 節で見たとおり、OCB は MDC と比べて性能・ハードウェア支援・構造的安全性のいずれの面でも優れている AEAD であり、特許も 2021 年にパブリックドメイン化された。技術的には「使わない理由がない」状態に到達したアルゴリズムである。
にもかかわらず、FreePG パッチを採用する Linux ディストロでは、デフォルトで OCB を生成しない、preference にも書かない設計が選ばれている。この設計判断は、技術的には**確かに「もったいない」**——せっかくの高性能アルゴリズムを、デフォルトでは抑制している。
ではなぜ「もったいない」を引き受けるのか。ここに「**性能の極大化**」と「**相互運用性**」の天秤がある：
- OCB を有効にすれば、ユーザは速い AEAD で暗号化できる
- しかし、その暗号化メッセージが Sequoia や ProtonMail（RFC 9580 専用実装）の受信者に届くと、復号できない事態が起きうる
- 暗号化メールを送信したユーザは「なぜ相手が読めないのか」を理解できない（透明な実装の差異が、不透明な障害として現れる）
メール暗号化において 0.1 秒の処理時間差は通常気にならないが、「相手が読めない」はユーザにとって致命的な体験である。FreePG プロジェクトのメンバーは、この天秤で**相互運用性に大きく重みを置いたと見られる**(仮説)。
別の比喩を用いるなら、これは「**性能のいいスポーツカーを持っているが、子供が同乗するときはチャイルドロックをかける**」ような判断である。スポーツカー（OCB）の性能は損なわれないが、デフォルトで保守的に振る舞う。「フル性能を出すには明示的にロック解除（`--compliance=gnupg`）してください」という設計。子供（受信者の OpenPGP 実装）が乗っているかどうかは送信者には見えないため、デフォルトで保守的にガードを効かせる、という判断は、暗号通信において合理的である。
そして、この設計判断は**永続的なものとして提示されているわけではない**。レポート 6.3 節で引用した Daniel Kahn Gillmor 氏（Debian GnuPG パッケージャー、FreePG メンバー）の言葉：
> In the ideal case, of course, we'd eliminate all our divergence from upstream, but that would depend on upstream being interested in working with the use cases and concerns that our users have.
参考訳：理想的には我々は上流からの乖離をすべて取り除きたいが、それには上流が我々のユーザーの使い方や懸念に応じることに関心を持つかどうかにかかっている。
FreePG メンバー自身が、この乖離を「永続的なもの」とは見ていない。FreePG パッチは「**OpenPGP / LibrePGP 分岐が解消されるまでの暫定的な抑制策**」と読むこともできる。両陣営が OCB のパケット形式について収斂すれば、FreePG パッチは「もったいない」を解消できる。
この「**最適性能を追わず、適度に非効率を引き受けて相互運用性を確保する**」という設計判断は、システム設計における重要な姿勢の一つである。最適化の極大化を追えば構造が脆くなり、外部環境の変化（今回でいえば LibrePGP / RFC 9580 分岐）に対する耐性が失われる。**完全な最適化ではなく、適度な余白を残した設計こそが、長期的なレジリエンスの源泉**となる——FreePG プロジェクトの「もったいないけど最大互換性」という選択は、この姿勢の具体例として読み解けるのではないか。
### 7.4 ユーザーが意識すべき点（実用的な指針）
#### 7.4.1 前提：鍵フォーマットのバージョンとアルゴリズムは独立
OpenPGP の鍵には**二つの独立した属性**がある：
| 属性 | 何を決めるか | 選択肢 |
|---|---|---|
| 鍵フォーマットのバージョン | パケット構造、フィンガープリント計算方式、自己署名の構造等 | v4（RFC 4880）/ v5（LibrePGP）/ v6（RFC 9580）|
| 暗号アルゴリズム | 公開鍵暗号の種類と鍵長 | RSA、Ed25519、Cv25519、ECDSA 等 |
両者は独立しており、技術的には「Ed25519 を v4 鍵で生成する」「RSA を v6 鍵で生成する」といった組み合わせも可能である。ただし、実用ツールのデフォルト挙動では事実上の相関が生じる。たとえば RFC 9580 の v6 鍵フォーマットは Curve25519/X448 等の楕円曲線中心の設計であり、ProtonMail GopenPGP のコメントでは「Note that RSA keys should not be generated anymore according to RFC 9580」と明記されている[^15]。結果として、RSA 4096 を選ぶと実用上は v4 鍵になる傾向が強いが、これは保証ではなく実装ごとのデフォルト挙動の結果である。
#### 7.4.2 実装ごとのデフォルト挙動（参考）
| 実装 | デフォルトの鍵フォーマット |
|---|---|
| Sequoia PGP（`sq key generate` デフォルト） | v4（互換性のため）[^27] |
| Sequoia PGP（`sq key generate --profile rfc9580`） | v6 |
| GnuPG 上流純正 2.4.9（oldstable、FreePG パッチなし、自前ビルドで検証） | **v4 鍵**（compliance mode = `gnupg` でも、通常鍵生成のデフォルトは v4）[^29] |
| GnuPG 上流純正 2.5.19（stable[^30]、PQC 対応、FreePG パッチなし、自前ビルドで検証）の通常鍵生成 | **v4 鍵**（2.4.9 と同じ）[^31] |
| GnuPG 上流純正 2.5.19 の PQC 鍵生成（Kyber 768 (bp256)）| **v4 主鍵 + v5 PQC 副鍵のハイブリッド**[^31] |
| GnuPG（FreePG パッチ込みの主要 Linux ディストロ） | **v4 鍵**（Kubuntu 26.04 LTS / GnuPG 2.4.8 環境で実検証）[^28] |
注：上表のうち Sequoia PGP のデフォルト挙動は ArchWiki の一次記述で、GnuPG 関連のデフォルト挙動はそれぞれ自前ビルド + 環境分離による実検証で確認済み。LibrePGP 路線の PQC 鍵生成では「主鍵は v4 のまま、PQC 副鍵のみが v5」というハイブリッド構造が採用されており、これにより既存の v4 鍵基盤との互換性を保ちつつ PQC 機能が追加できるよう設計されている。
#### 7.4.3 通常のユーザー（個人利用）の指針
通常のユーザー（個人利用）であれば、以下を意識するだけで十分と考えられる：
1. **互換性が必要なら、デフォルトの鍵生成設定を維持する**：主要 Linux ディストロや Sequoia の `sq key generate`（オプションなし）のデフォルト動作のままでよい。多くの実装でデフォルトは v4 鍵
2. **アルゴリズムは「Ed25519 + Cv25519」または「RSA 4096」を選ぶ**：いずれも両陣営で読める。Ed25519/Cv25519 は GnuPG の現行デフォルトであり[^29][^31]、性能も優れる。RSA 4096 は最も互換性が高い古い選択肢で、極めて古い OpenPGP 実装と通信する場合の選択肢として残る
3. **v6 鍵フォーマットの新規生成は慎重に**：Sequoia の `--profile rfc9580` を明示的に指定した時のみ生成される。相手の実装環境を確認してから
#### 7.4.4 技術的に踏み込むユーザーの追加の指針
技術的に踏み込むユーザー（OSS 開発者、パッケージメンテナー、長期運用を要するシステム管理者）であれば、追加で以下を意識する価値がある：
1. **自身が使うツールチェーンがどちら側か**：GnuPG（FreePG パッチ込み）か、Sequoia/RNP/OpenPGP.js 系か
2. **生成された鍵のフォーマット確認**：以下のコマンドで確認できる
- GnuPG：`gpg --export <KEYID> | gpg --list-packets | grep -E "^:public|^\s+version"`
- Sequoia：`sq inspect <key.pgp>`
出力中の `:public key packet:` および `:public sub key packet:` セクションの直下にある `version N` を読む。`version 4` なら v4 鍵、`version 5` なら v5 鍵、`version 6` なら v6 鍵である。なお `gpg --export` は公開鍵のみを取り出すコマンドであり、秘密鍵は出力されない（ハードウェアトークン格納の鍵にも影響を与えない）
3. **通信相手のツールチェーンとの整合性**：双方の実装が共通サポートする鍵フォーマット（多くの場合 v4）を選ぶ
4. **PQC 移行への準備**：両陣営の動向を継続的にウォッチ
### 7.5 PQC 移行への含意
PQC 移行は両陣営の分岐をさらに複雑にする可能性がある[^24]：
- **IETF OpenPGP**：draft-ietf-openpgp-pqc が standards-track で進行中。2026年前半に RFC 化が予測されている
- **LibrePGP**：GnuPG 2.5 で独自に PQC 実装を進めている
副鍵を PQC 対応に切り替える際、自身のツールチェーンと通信相手のツールチェーンが整合しているかを確認することが、特に長期保護用途では重要となる。移行期は「従来鍵」「PQC v6 鍵（RFC 9580/PQC 系）」「PQC v5 鍵（LibrePGP 系）」が併存する可能性があり、副鍵の有効期間を意図的に短めに設定して移行のタイミングを早めに迎えられるようにする戦略にも合理性がある。
Sequoia PGP は 2025年11月に PQC 対応のプレビュー版（sequoia-sq 1.4.0-pqc.1）を公開した[^23]。Red Hat は RHEL 10.1 でこの実装を取り込み、ML-DSA-87 + Ed448 のハイブリッド鍵で RPM パッケージへの PQC 署名を開始しており、Linux ディストリビューションとしては初めての PQC 署名済みパッケージリリースと自認している[^25]。これは「IETF OpenPGP / RFC 9580 路線の PQC 実装」が、主要 Linux ベンダーによる商用環境への展開段階に入ったことを意味する重要な動きである。
---
## 8. 残された論点と今後の見通し
### 8.1 残された論点
- **macOS / GPG Suite の正確な立ち位置**：LibrePGP 公式サポーターリストに掲載されているが、デフォルト挙動の一次情報での確認は十分にできていない。MacGPG のソースコードまたは GPGTools 公式の方針表明の確認が必要
- **Arch Linux での FreePG パッチ適用状況の詳細**：本レポートの実検証は Kubuntu 26.04 LTS で行ったものであり、Arch Linux で同じ FreePG パッチセット（特に 0024/0026）が採用されているか、`--full-gen-key` 時の AEAD: OCB に関する ArchWiki の警告が現時点で実態と一致するかは未検証である
- **Sequoia PGP Blog の "v5 artifacts" の具体的内容**：「v5 アーティファクト」が PQC 副鍵以外のどのパケット種類（署名、暗号化メッセージ等）を含むかは、本レポートでは原典の表現以上の詳細確認はできていない。本レポートの実検証では「PQC 副鍵が v5 で生成される」という事実は確認できたが、その他の v5 アーティファクト（v5 署名等）の生成条件は別途確認が必要
- **Thunderbird の今後の方針**：RNP 内蔵という現状が継続するのか、別の実装（Sequoia 系等）への切替が検討されるのか
- **ProtonMail の Web/Mobile クライアントでの実装挙動**：v3 ライブラリは RFC 9580 をサポートするが、実際のユーザー側でデフォルトで生成される鍵フォーマット（v4/v6）の挙動は別途確認が必要
### 8.2 今後の見通し
短期的（1〜2年）に予想される動向：
- 主要 Linux ディストロは FreePG パッチを継続採用し、デフォルトで RFC 9580 互換を維持する
- Sequoia PGP（→ Fedora の sq）の利用が拡大する可能性
- PQC 規格の RFC 化（2026年前半予測）により、両陣営の対応がさらに加速
中期的（3〜5年）に注目すべき動向：
- IETF（RFC 9580）と LibrePGP の関係（統合・棲み分け・収斂）
- v6 鍵フォーマットの普及度
- PQC 副鍵への移行の進展
これらの動向は、今後数年で実装エコシステム全体に影響する可能性が高く、継続的な追跡が必要である。
---
## 9. 参考情報源
### 9.1 RFC 9580 / OpenPGP
- IETF RFC 9580（OpenPGP、2024年7月）
- OpenPGP.org（OpenPGP プロジェクト公式）
- RFC 9580 サポート実装：Sequoia PGP、ProtonMail（OpenPGP.js / GopenPGP）等
### 9.2 LibrePGP
- LibrePGP 公式サイト（librepgp.org）
- GnuPG 公式サイト
- Gpg4win 公式サイト
### 9.3 FreePG
- FreePG 公式サイト（freepg.org）
- FreePG ガバナンスページ
### 9.4 関連メディア・記事
- LWN.net "A schism in the OpenPGP world"（2023-12）
- Sequoia PGP Blog "Out and About"（2024-09）
- DidiSoft "OpenPGP updates, LibrePGP and RFC 9580"
---
## 脚注
[^1]: A schism in the OpenPGP world (LWN.net、2023-12). https://lwn.net/Articles/953797/ (2026-05-09 閲覧)
[^2]: RFC 9580: OpenPGP. https://www.rfc-editor.org/rfc/rfc9580.html (2026-05-09 閲覧)
[^3]: Sequoia PGP Blog "Out and About"（OpenPGP / LibrePGP 分裂についての記述あり） (2024-09-04). https://sequoia-pgp.org/blog/2024/09/04/202409-out-and-about/ (2026-05-09 閲覧)
[^4]: FreePG Project 公式サイト. https://freepg.org/ (2026-05-09 閲覧)
[^5]: GnuPG - ArchWiki（GnuPG 独自 AEAD 機構の互換性問題に関する記述）. https://wiki.archlinux.org/title/GnuPG (2026-05-09 閲覧)
[^6]: FreePG Project Governance（プロジェクトメンバー一覧およびガバナンス方式）. https://freepg.org/governance/ (2026-05-09 閲覧)
[^7]: Notes on OpenPGP（Thunderbird が RNP を内蔵することの記述）. https://openpgp.dev/book/openpgp.html (2026-05-09 閲覧)
[^8]: RNP 公式サイト（LibrePGP サポート発表）. https://www.rnpgp.org/ (2026-05-09 閲覧)
[^9]: Arch Linux gnupg パッケージのマージリクエスト「Switch to common patches maintained by freepg project」. https://gitlab.archlinux.org/archlinux/packaging/packages/gnupg/-/merge_requests/8 (2026-05-09 閲覧)
[^10]: pacman/Package signing - ArchWiki. https://wiki.archlinux.org/title/Pacman/Package_signing (2026-05-09 閲覧)
[^11]: Gpg4win 公式サイト. https://www.gpg4win.org/ (2026-05-09 閲覧)
[^12]: LibrePGP 公式サイト（Gpg4win や RNP、GPGTools に関する記述）. https://librepgp.org/ (2026-05-09 閲覧)
[^13]: GPG Suite (GPGTools) 公式サイト. https://gpgtools.org/ (2026-05-09 閲覧)
[^14]: ProtonMail/openpgpjs README（"It implements RFC 9580" の記述）. https://github.com/ProtonMail/openpgpjs (2026-05-09 閲覧)
[^15]: ProtonMail/gopenpgp v3 README（RFC9580 プロファイル、v6 鍵生成等の記述）. https://github.com/ProtonMail/gopenpgp (2026-05-09 閲覧)
[^16]: Debian GNU/Linux 13 (trixie)（DEBIAN_VERSION_FULL=13.4、コードネーム trixie）環境での実検証結果。`gpg --list-keys --keyring /usr/share/keyrings/debian-archive-trixie-stable.pgp`、`gpg --version`、`gpg --list-config | grep -i compliance` の各コマンド出力。検証日：2026-05-09。Debian Stable Release Key (13/trixie) のフィンガープリントは 41587F7DB8C774BCCF131416762F67A0B2C39DE4、Ed25519、2025年3月24日発行、2033年3月22日まで有効。
[^17]: Kubuntu 26.04 LTS（DISTRIB_DESCRIPTION="Ubuntu 26.04 LTS"、コードネーム resolute）環境での実検証結果。`gpg --list-keys --keyring /usr/share/keyrings/ubuntu-archive-keyring.gpg`、`gpg --version`、`gpg --list-config | grep -i compliance` の各コマンド出力。検証日：2026-05-09。
[^18]: Kubuntu 26.04 LTS / GnuPG 2.4.8 環境で `gpg --full-generate-key --expert` で生成した ed25519 鍵の preferences を `gpg --edit-key <FINGERPRINT> showpref` で確認した結果。setpref による preferences 変更は実行していない（有効期限変更のみ）。検証日：2026-05-09。
[^19]: Kubuntu 26.04 LTS の gnupg ソースパッケージを `apt source gnupg` で取得し、`debian/patches/series` を確認した結果。FreePG プロジェクト由来のパッチが計 22 個含まれていた。検証日：2026-05-09。
[^20]: Bug#1093026: marked as done（gnupg24 ITP のクローズ宣言、Simon Josefsson 氏と Daniel Kahn Gillmor 氏のやり取り）. https://lists.debian.org/debian-wnpp/2025/02/msg00705.html (2026-05-09 閲覧)。なお、Bug#1093026 の元 ITP 投稿は https://www.mail-archive.com/
[email protected]/msg269631.html（2026-05-09 閲覧）。
[^21]: Gpg4win - Impressum（開発主体の一次情報）および gpg/gpg4win GitHub mirror（README.md の Copyright 表記）. https://gpg4win.org/impressum-de.html および https://github.com/gpg/gpg4win (2026-05-09 閲覧)
[^22]: Fedora Project security page (sq verify command examples). https://getfedora.org/security/ (2026-05-09 閲覧)
[^23]: Sequoia PGP の PQC 対応プレビュー版（sequoia-sq 1.4.0-pqc.1、2025-11-13 公開）に関するアナウンス（Neal H. Walfield、2025-11-15）. https://sequoia-pgp.org/blog/2025/11/15/202511-post-quantum-cryptography/ (2026-05-09 閲覧)
[^24]: draft-ietf-openpgp-pqc（IETF OpenPGP WG の PQC ドラフト）. https://datatracker.ietf.org/doc/draft-ietf-openpgp-pqc/ (2026-05-09 閲覧)
[^25]: What's new in post-quantum cryptography in RHEL 10.1（Red Hat Blog）. https://www.redhat.com/en/blog/whats-new-post-quantum-cryptography-rhel-101 (2026-05-09 閲覧)
[^26]: Jason Self, "The OpenPGP Schism" (2025-11-23). https://jxself.org/openpgp.shtml (2026-05-09 閲覧)
[^27]: Sequoia PGP - ArchWiki（"By default sq generates keys according to the old RFC4880 in order to maintain compatibility with GnuPG and other old OpenPGP implementations." の記述）. https://wiki.archlinux.org/title/Sequoia_PGP (2026-05-09 閲覧)
[^28]: Kubuntu 26.04 LTS（DISTRIB_DESCRIPTION="Ubuntu 26.04 LTS"、コードネーム resolute）/ GnuPG 2.4.8 環境で生成された Ed25519 主鍵 + ECC 副鍵（×3、algo 19/19/18）の鍵フォーマットを `gpg --export | gpg --list-packets | grep -E "^:public|^\s+version"` で確認した結果、主鍵・副鍵ともに version 4 であることが確認された。algo 22（EdDSA Legacy）、algo 19（ECDSA）、algo 18（ECDH）の各値は RFC 9580 Section 9.1 と整合する。検証日：2026-05-09。
[^29]: GnuPG 2.4.9 を上流ソース（gnupg-2.4.9.tar.bz2、speedo によるビルド）から自前ビルドし、$HOME/local/gnupg-2.4.9 に独立した prefix でインストール、`GNUPGHOME=$(mktemp -d)` で環境を分離して実検証した結果。`gpg --gpgconf-list | grep -i compliance` の出力は `compliance:16:"gnupg:` で、デフォルト compliance mode は `gnupg`（LibrePGP 路線）。`gpg --batch --passphrase '' --quick-generate-key "Test User <
[email protected]>" default default never` で生成された鍵を `gpg --export | gpg --list-packets` で確認したところ、主鍵 algo 22（EdDSA Legacy）+ 副鍵 algo 18（ECDH/Cv25519）、いずれも version 4。`gpg --edit-key ... showpref` の出力では「AEAD: OCB」と「Features: MDC, AEAD, Keyserver no-modify」が含まれていた。検証日：2026-05-09。
[^30]: GnuPG 公式 Download ページ. https://www.gnupg.org/download/index.html (2026-05-09 閲覧)。同ページのリリース表では GnuPG 2.5.19（2026-04-24 公開）を「(stable)」、GnuPG 2.4.9（2025-12-30 公開）を「(oldstable)」と分類している。End-of-life の表でも「2.5, 2.6」が現行および次期 stable として示されている。
[^31]: GnuPG 2.5.19 を上流ソース（gnupg-2.5.19.tar.bz2、speedo によるビルド）から自前ビルドし、$HOME/local/gnupg-2.5.19 に独立した prefix でインストール、`GNUPGHOME=$(mktemp -d)` で環境を分離して実検証した結果。`gpg --version` の Pubkey 行は「RSA, Kyber, ELG, DSA, ECDH, ECDSA, EDDSA」で、PQC（Kyber）対応がビルド時に有効になっていることを確認。デフォルト compliance mode は `gnupg`。**通常鍵生成**（`gpg --batch --quick-generate-key ... default default never`）では、主鍵 algo 22（EdDSA Legacy）+ 副鍵 algo 18（ECDH/Cv25519）、いずれも version 4 が生成された。**PQC 鍵生成**（`gpg --full-generate-key --expert` で「(16) ECC と Kyber」→「(1) Kyber 768 (bp256)」を選択）では、主鍵 algo 19（ECDSA、Brainpool P-256）version 4、PQC 副鍵 algo 8（Kyber 768）version 5、pkbytes 1265、副鍵バインディング署名 version 4 が生成された。pinentry はシステム環境（Kubuntu 26.04 LTS）の `/usr/bin/pinentry` を `$GNUPGHOME/gpg-agent.conf` 経由で借用。検証日：2026-05-09。
[^32]: Ubuntu Manpages: gpg(1) - https://manpages.ubuntu.com/manpages/stonking/man1/gpg.1.html （2026-05-09 閲覧、Ubuntu 26.10 stonking、gpg 2.4.8-4ubuntu3）。Debian Manpages: gpg(1) - https://manpages.debian.org/trixie/gpg/gpg.1.en.html （2026-05-09 閲覧、Debian 13 trixie）。両者の "Compliance options" セクションは本文に引用した記述を含み、内容は完全に一致する。あわせて、本レポート執筆者のローカル環境（Kubuntu 24.04 および Debian 13 trixie）で `man gpg` を実行し、同一の記述が表示されることも確認した。検証日：2026-05-09。