OpenPGPとLibrePGP―GnuPGとそれ以外の実装での対立

更新履歴

2025-07-09 初版公開
2025-07-09 文体や重複を修正、リンクを追加、論旨の明確化、目次の追加

PGP鍵はまだ貼っていない

導入

GnuPG(gpg)は公開鍵での署名や暗号化においてはデファクトスタンダードといえる実装だろう。実際、多くの配布物で署名の検証にgpgを使うよう指示されるし、Debian系のapt、Arch系のpacman等々のパッケージマネージャー、Gitのコミット署名でもgpgを使うのがほぼ常識であろう。そんなGnuPGは、今まではOpenPGPと呼ばれるインターネット標準(RFC 4880)に準拠していた。ただ、EdDSA関連などはRFC 4880bisという暫定版に準拠しながら実装してきた。

本稿は、要するにこのGnuPGがOpenPGPから逸脱することになったという話である。主に自身の経験ともどかしさをまとめようと筆を執ったが、OpenPGPをめぐる現状は（WikipediaやArch Wikiを見れば日本語でもわかるものの）ユーザーレベルではあまり知られていないようだ。その影響範囲も鑑み、周知のために記しておく。

エッセイ調でありながら技術の内容も含む。最後にPGP鍵のリンクを貼るつもりである。全文をお読みいただく必要はないが、現状のGnuPGの実装がOpenPGPと異なっていることをご理解いただかないと、この鍵の取り込みに支障をきたす可能性があるため、ご注意願いたい。

気づき

楕円曲線を用いた暗号について概説しておくと、ECDSAやECDHはどんな楕円曲線（楕円とは別物である）上でも（セキュリティを考えなければ）動作する。EdDSA(Edwards-curve DSA)はエドワーズ曲線と呼ばれる楕円曲線の特別なクラス上で動作する署名アルゴリズムになっている。ただし、いずれも有限体上で定義される楕円曲線を用いている。詳しくはWikipediaの楕円曲線暗号などを参照してほしい。

ECDSAやECDHは、名称の通り、DSAやDHを整数の離散対数問題ではなく、楕円曲線(Elliptic-curve)の（上に定まる加群の）離散対数問題で実装したものである。 EdDSA、そのうちEd25519は、ECDSAよりもDSAの署名方式に近い（Schnorr署名）ものである。Curve25519は、このEd25519で使われるエドワーズ曲線と数学的に構造が同じ曲線上でのECDHである。さらにいえば、ECDSAの曲線の一部の選定にはNSAの息が掛かっていたという疑惑があり、そのような恐れのないクリーンな曲線としてEd25519やCurve25519が流行している。

X25519と呼ぶときは、この曲線の「構造」が同じEd25519とCurve25519をまとめて指すことにする。本稿では、RSAやDHといった基本的な公開鍵暗号についての知識は前提とする。

X448

GnuPG 2.3.0では、X448、つまりed448とcv448が実装された。これ自体はTLS 1.3でサポートがされており、特に目新しい暗号というわけではない。 X25519という楕円曲線、及びEdDSA（エドワーズ曲線署名アルゴリズム）はGnuPGに既に実装されていたし、X25519はRFC 4880bisで定義されていた。

Curve25519やEd25519の利点として、鍵サイズ及び計算コストが少ないながらもセキュリティが高く、ECDSAにあった既知の理論的な脆弱性（nonceの再利用による秘密鍵の漏洩）が生じず、またサイドチャネル攻撃等の攻撃を避けるように実装や楕円曲線の選定が実施されている。 X448はその暗号形式自体はX25519と同様で、RFC 8032に定義されている。

RSAでは素因数分解アルゴリズムの進歩もあり、特定のセキュリティ強度¹に必要な鍵長が長くなっている。 128 bitならRSAでは3072 bitの鍵長、楕円曲線暗号(X25519など)では256 bitの鍵長²である。一般的な共有鍵暗号では、最近はAES-256（だいたい256 bitの強度）である。セキュリティは数々のアルゴリズムの最も弱いものが足を引っ張る(weakest link)ので、公開鍵暗号も128 bitのセキュリティ強度では物足りないということになってくる。そこで224 bitのセキュリティ強度で、かつ処理が高速なX448にスポットライトが当たることになる。

私もGnuPG 2.3.0がリリースされたときに、X448の実装がされていることを知り、喜んで使い始めた。（2021年ごろ）

問題の始まり

まず気づいたのは、GitHubへの公開鍵のインポートがうまくいかないことである。 X448を常用する気でいたので、わざわざGitHubやGit周りで使うための鍵を個別に生成した（これはGit経由でメールアドレスを公開したくないというのもあった。当時はusers.noreply.github.comがverified emailとして認識されていたはずなので、これを使うとメールアドレスを隠蔽できた）。

まあ新しいアルゴリズム（だし、GnuPG 2.3.xはパブリックベータ扱い）なので、GitHubが対応していないのは仕方がないと思っていた。ここから4年が経った今、この問題が実はより大きな問題であることに気づいた。

LibrePGP

GnuPG 2.3.x系列が安定したとみなされ、GnuPG 2.4.x系列が安定版として実装された。これを（2.3のように喜んで）インストールしたつもりはないが、気づいたらアップデートされていたわけである。その間にsksのpoolが死に、keys.openpgp.orgが立ち上がった。公開鍵の共有基盤も大きく変化していた。

ちょっと暇が出来たので、公開鍵を整理して、自宅鯖にWKD(WKS)³を置いたり、DNSで公開鍵を公開することをふと思い立った。まずWKDはCF Pagesで動作しなかったので、自宅鯖の稼働と並行してDNSのCERTに公開鍵を置こうと試みた。

UIDや副鍵で遊びまくって肥大化していたので、当然CERTレコードには乗らず、DNS向け公開鍵を作ることにした。それ自体はスムーズに進んだが、終わった後、fingerprintが長いことに気づいた。これ自体は、MD5からSHA-1への移行、そして近年になってSHA-1の危殆化が現実的になってきたので、SHA-256になったのだろうと思ったが、これは何かしらの標準が変わったことを意味している。そのときはまだ調べようと思うことはなかった。

既存のPGP鍵を整理し、本ウェブサイトにアップロードした後、GitHubにアップロードしようと試みた。しかしながら、よくわからないエラーが出て弾かれた。gpgpdumpで分析しようとgpgからエクスポートして渡してみてもエラーが出る。この現象はX448を含まない（つまり、これまでアップロードできていた）鍵でも発生したため、相当困惑した。

まず当たったのは OpenPGP で利用可能なアルゴリズム（RFC 9580 対応版） | text.Baldanders[.]info である。gpgpdump作者のWebサイトであり、ここでどうやらOpenPGPのRFCが更新されたらしいことを知った。

そういえばGnuPGに変なブログ記事が上がってたなと思い見てみると、My thoughts on Sequoia PGP and LibrePGPがあった。最初に斜め読みしたときはSequoiaとGnuPGの争いやソフトウェア哲学のレベルの議論だと思っていたが、RFC 9580（著者にGnuPG関係者がいない！）を見た後だとこれは標準化のレベルの争いであった。

この争いを浅学ながら要約しようと試みると以下⁴である:

OpenPGP(RFC 4880)は様々な点で古いので改訂が必要である
GnuPGとPGP（プロプライエタリの方）で中間的な内容としてRFC 4880bisが制定、X25519などの導入が進む（2018年頃から改訂に向けIETFワーキンググループが再始動？）
GnuPGのメンバーとそれ以外のメンバーで保守的な変更と進歩的な変更⁵で対立し、膠着状態に
GnuPGのメンバーがワーキンググループ脱退？
Proton MailやSequoia-PGPあたりがRFC 4880bisを大きく書き換える方針(crypto-refresh)に転換
結果として4880bisに近いLibrePGPと正式なRFCになったRFC 9580の2つの標準が対立中

当然、GnuPGは2.4.0以降はRFC 9580としてのOpenPGPに従わないことを表明し、LibrePGPに準拠することになっている。ところがIETFが定める標準としてはOpenPGPであるから、（多くのソフトに組み込まれるGnuPGという）デファクトスタンダードと明文化された標準があからさまに衝突している。これが問題の概略である。

実際の問題

RFC 4880bisに近いLibrePGPとOpenPGP(RFC 9580)の違いは以下に要約できる。ちなみに、v4が今まで使われていた内部バージョン番号である。

LibrePGPは内部的にv5というバージョン番号を使い、OpenPGPはv6を使う（v5は欠番）
- 番号がfingerprintに絡んでくるため当然一致しない
AEADの仕様の食い違い
耐量子暗号についての立場の違い

LibrePGPからOpenPGPへの批判 A Critique on the OpenPGP Updatesから要約（順序を入れ替えるなどしている）

LibrePGPはOCBという認証用の暗号利用モードを使いAEADを行う。
1. 要は、PGPで暗号化する際、改ざんされていないことが証明できるような暗号化の仕方になる。
2. OpenPGPはより実装が複雑なGCMを採用していると非難
4880bisで定義されていたECDHの仕様を破壊して車輪の再発明をしている。
キーの失効者の無効化、データのマークに使うフラグの仕様変更
暗号化や署名にパディングやソルトを入れる
1. LibrePGPはそれはアプリケーションのレイヤーがやることで暗号化ソフトではないと反発、特に情報漏洩の抜け道になりかねない。
アルゴリズムが多すぎ
1. HKDFやArgon2などは不要だろう
2. 暗号利用モードが多い
そもそもお前らが合意を乱したのでは？そしてオンライン用に特化しているのでは？

OpenPGP側による再反論 A Critique on “A Critique on the OpenPGP Updates” | blog.pgpkeys.euから要約（同上、上と番号が対応するようにした）

GCMの実装の複雑さは、ライブラリが豊富にあるから問題にならないし、そもそもOCBは今のRFC 9580に必須として入っている
1. すでに解決された問題であるとのこと
ECDHの実装は一時的なものだったし、本質的な変更は一切ない
キーの失効者の仕組みに合理的な根拠はなく、失効証明書で十分である。さらにフラグの仕様変更はテキストのエンコードが不明なのが問題で、utf-8を指定するようにした（実際それはデファクトスタンダード）。
情報漏洩の抜け道は他にいくらでもあるし、ソフト側で許可or不許可すれば十分である。さらに、OpenPGP自体は鍵のやりとりなどでアプリケーションとして動くので批判はあたらない。
HKDFとArgon2は既知or潜在的な脆弱性の対応のために追加したもので、LibrePGPはそれに対応できていない。
1. 暗号や暗号利用モードについてはOptionalだし、歴史的経緯もある（原文参照）
批判で挙がっているものにはWernerがWGで折衷案として提案して記録に残っているものもある。GCM以外の批判はほとんど誇張かIETFの手続き上の問題。
1. 後者であればIETFの異議申し立て(appeal)をすべきものだが、一切していない
2. オンライン向きという批判は基本的に当たらない

さらに、LibrePGPには2024年8月段階でOpenPGPにない理論上の脆弱性が存在する A Summary of Known Security Issues in LibrePGP | blog.pgpkeys.eu

v5署名のダウングレード
Type 20 “OCB Packet” の可塑性攻撃
秘密鍵上書き攻撃
- OpenPGPではAEADで秘密鍵を保護することでそのような攻撃を防いでいる

LibrePGPもOpenPGPもお互いを相当攻撃しており⁶、もはや戦争の様相を呈している。私にはどちらが良いか判断できる能力や経験はないが、少なくともGnuPGとopenpgp.js,gopenpg（この2つはProton Mail）やSequoia、そしてIETFの標準というのが対立しているのはユーザーにとって非常に面倒な状況である。また、暗号化アルゴリズムの推奨としてはやはりOpenPGPの方が一枚上手な感触がある。RSAの非推奨はかなり良い判断であると個人的には思う。ちなみに、keys.openpgp.orgの運営からもGnuPGのデベロッパーは排除されているようである。keys.openpgp.org governance

結び

この惨状がいつ改善するのか、はっきりしない。SequoiaはまだGnuPGほどユーザーベースを拡大できていない（個人的には元？母体のpEpが信用ならない）。GnuPGは既にOpenPGP対応バージョンを廃止しており、今後RFC 9580に従うことはないだろう。そして、これはSequoia側にしても同様で、LibrePGPに準拠することはないはずだ。

GitHubが「GPG鍵」という名称を使いながら、最新のGnuPGと互換性がない現状には、正直やるせない気持ちになる。とはいえ、一縷の望みはある。（SequoiaでもGnuPGでもない）第三のPGPクライアント実装が、v4鍵に加えてv5とv6の両方を受け入れるようになれば、一旦の解決は見込めるかもしれない。少なくともOpenPGP側はその方針を取っており、Proton Mailが開発するライブラリであるOpenPGP.jsとGopenPGPもその方向で実装を進めているようだ。

当分の間、我々としてはGnuPG - ArchWiki記載の回避策を実施してなんとかやり過ごすくらいしかできないのではないかと思う。いつか多くの人が納得する標準が制定されることを願い、この記事を閉じる。

私の方針

一時的に公開鍵の公開を取りやめている。少なくともv5,v6の鍵を公開することは当分しない。詳しくは後に追記するつもりだ。

参考文献

記事内で引用していないものの一覧。

n bitのセキュリティ強度とは、平均的に攻撃に2^n回の計算が必要になることを指す。現代では128 bitのセキュリティ強度が最低限必要。 ↩︎
楕円曲線暗号のセキュリティ強度は、鍵長の半分程度になる。つまり、256 bitの鍵長の楕円曲線暗号は128 bitのセキュリティ強度を持つ。 ↩︎
WKD (Web Key Directory)は公開鍵をHTTPで公開する仕組み。DNSのほうはCERTレコードという専用のレコードに様々な種類の公開鍵を置くことができる仕組み。後者の信頼性を担保するDNSSECについても問題が多いがここでは扱わない。 ↩︎
人間関係の問題は情報が少ないため、GnuPG側の意見を参考にしつつ語調を弱めてある。 ↩︎
当然ながら政治の話ではない。 ↩︎
OpenPGP側はLibrePGPのウェブサイトを止めろと言っているし(“A Critique on “A Critique on the OpenPGP Updates””, 前出)、GnuPGの公式ブログ(“My thoughts on Sequoia PGP and LibrePGP”, 前出)ではSequoiaが過去の遺物になることを願っているし、この論争の原因になった空気はSequoiaのせいとまで言っている。 ↩︎