In 2026, my main focus is the https://codeberg.org/minipgp6/ #OpenPGP stack.
#minipgp6 is a very small implementation of a minimal modern subset of OpenPGP, in #Rust.
The project aims to be both a comprehensive introduction to OpenPGP (for anyone who wants to approach the ecosystem from the shallow end) as well as practically useful software for contexts that don't require backward-compatibility with legacy formats.
(Many thanks to @nlnet for supporting this project!)
@hko @nlnet From the codeburg page for the project:
>GnuPG has opted to instead fork the OpenPGP standard and go its own incompatible path.
This badly misrepresents the situation. If there was a fork it would be on the part of the RFC-9580 faction. After a process that involved GnuPG came up with a proposal the 9580 faction didn't like that faction came up with their own standard, deliberately and vindictively making it completely incompatible with the existing proposal (now called LibrePG).
None of that matters now. If the two factions keep promoting their incompatible proposals the result will be in interoperability disaster.
@upofadown I don't know why you keep reiterating this argument.
There is a large group of implementers who have opted to collaborate at the IETF, and who have all built interoperable implementations of RFC 9580.
On the other side, there is GnuPG, who is going a solitary separate path (and RNP, who implement parts of GnuPG's "LibrePGP" draft).
These are simple facts. RFC 9580 went through the IETF process, and it enjoys massive consensus in the space.
@upofadown If you want to talk about "vindictive incompatibility", a better example of that is the absolutely bizarre decision of #GnuPG to break away from https://datatracker.ietf.org/doc/draft-ietf-openpgp-pqc/
GnuPG forked that draft with barely a pretense of an actual reason, and is now seemingly trying to speedrun a rollout of that incompatible non-IETF #PQC format (including by apparently trying to nudge people to switch to the 2.5.x series by avoiding tagging new releases in the 2.4 series)
This document defines a post-quantum public key algorithm extension for the OpenPGP protocol, extending RFC9580. Given the generally assumed threat of a cryptographically relevant quantum computer, this extension provides a basis for long-term secure OpenPGP signatures and ciphertexts. Specifically, it defines composite public key encryption based on ML-KEM (formerly CRYSTALS-Kyber), composite public key signatures based on ML-DSA (formerly CRYSTALS-Dilithium), both in combination with elliptic curve cryptography, and SLH-DSA (formerly SPHINCS+) as a standalone public key signature scheme.
@upofadown Ok, this is getting a bit silly.
Someone defined the v6 key and signature formats "to avoid being compatible"?
Please underpin this unhinged insinuation of intent with a source, or retract it. That is not a reasonable thing to write.
@neverpanic "v6" keys/signatures in RFC 9580 are the successor formats for the v4 formats from earlier RFCs, as designed by the IETF OpenPGP WG.
They represent the WGs collective design choices during the crypto refresh cleanup.
While the WG worked on the draft that turned into RFC 9580, these formats were initially specified as "v5".
Late in that drafting process it became clear that GnuPG had no intention of implementing RFC 9580, but instead would squat version 5 for its own ad-hoc formats.
@upofadown I can't tell if you don't understand the history or the format enough, or if you're trying to argue in bad faith.
Either way, this is not productive and I will disengage for now.
As I see it, this whole schism can really only end in two ways:
With all of OpenPGP falling into irrelevance, or with only GnuPG falling the rest of the way out of favor in the floss world.
I know which of the two outcomes I prefer. Maybe you can try to figure out what your preferred (possible) outcome is.
@upofadown GnuPG excluded itself from the IETF process by effectively refusing to engage. A lot of people have attempted to build bridges, but GnuPG refused them all. There is no reasonable complaint in that corner.
And sure, infrastructure has inertia. But it's not forever. The relevance of GnuPG in the Free Software world has shrunk massively. And I don't see that trend stopping, given current events.
@hko I was paying attention at the time. The process was at that point never ending. Koch was not the only one ignoring it to preserve their sanity. I don't think any reasonable person would have assumed that the process had not died, just like in the previous cases.
OK, since you support the RFC-9580 faction, what has that faction offered to compromise on recently? Or ever? The only thing I remember was an offer to get rid of the EAX block encryption mode, which no one wanted anyway. Bizarrely, the EAX mode is still in the RFC-9580 proposal which doesn't really show good faith.
@upofadown I don't support a "faction". I believe the IETF process is our best shot at a reasonable process.
Sure, it's flawed. But it's less flawed than some personal fiefdom that attempts to bully an ecosystem into submission with a half-baked draft (and an implementation that does not spark joy in many readers).
Your argument seems to boil down to mostly "(self-imagined) might makes right".
EAX is also in draft-koch-librepgp.
>EAX is also in draft-koch-librepgp.
Yes, but that is because it existed for a long time in the draft. That's the issue with this sort of standard. You can't get rid of anything by just dropping it from the standard once someone has used it somewhere. It's a long annoying process. EAX is completely deprecated and creation of new EAX messages is not allowed. Quoting from sec 5.16.1:
>EAX mode is deprecated due to the far better properties of the OCB mode. Implementations may use EAX mode only for decryption of existing data.
I would not be surprised to see EAX entirely dropped in a later revision of the LibrePGP proposal.
GCM mode came as part of the split and is not mentioned at all.
@upofadown readers are free to trust or dismiss my claim that offers of compromise have been made to the author of GnuPG, including substantive ones in private conversations. Other attempts at bridging the schism have public footprints in gnupg-devel.
To my knowledge all attempts at bridge-building (by an extremely broad range of actors) were either rebuffed or ignored.
(I'm not going to further litigate the point in this thread though.)
> GCM mode came as part of the split and is not mentioned at all.
Why are you making this point? I'm sure you are aware why that mode was added? It's the only AEAD mode that is currently available for efficient use in browsers.
OpenPGP uses signaling for the AEAD mode that users are willing to receive. So users have to explicitly opt in to using GCM (and they can opt out later, with a key update). No one is forced to use it, and implementations are free to reject the mode.
@hko My understanding is that GCM is a significant point of contention in the OpenPGP standards schism. So it would be relevant here. I have not seen any evidence presented that it would be more efficient than OCB for web applications. My estimation is that it would not be. Even if it was, the sorts of things done as web apps involve short messages (email).
That signalling that you mention (the preferences in the public key) only works for asymmetrical encryption and is not reliable. I have an entire page of examples of where it has failed:
https://articles.59.ca/doku.php?id=pgpfan:noae_shame
... and that is up to now just for a single implementation. Things could get much worse. That page is a reference for this article:
https://articles.59.ca/doku.php?id=pgpfan:interop
Somewhat ironically, it can be legitimately argued that CGM is overall less secure than the existing OCFB-MDC (SEIPD) mode:
https://articles.59.ca/doku.php?id=pgpfan:seip
The relative insecurity of GCM has also come out as a factor in the schism.
> That signalling that you mention (the preferences in the public key) only works for asymmetrical encryption and is not reliable. I have an entire page of examples of where it has failed
Uh ... I don't think this list centers around examples of what we're talking about here.
Your links seems to be largely examples of problems caused by GnuPG making relatively aggressive preference changes on behalf of its users (esp.: unilaterally enabling the GnuPG "type 20" encryption mode).
@upofadown Breaking users is bad. We're in agreement there.
But why do you keep raising concerns in threads where people discuss moving OpenPGP forward in the IETF framework, while I see zero mails from you on gnupg-devel about GnuPG's frivolous enabling of the "features subpacket" setting that signals user-opt-in for the "type 20" encryption container?
Here is a gnupg-users thread where I suggest that emitting new block modes (OCB here) is a Bad Idea™ when the schism exists:
https://marc.info/?t=170955787300002&r=1&w=2
I think it has come up less directly in my interaction with the mailing lists as well. I think that at this point it counts as a point of contention between me and the GnuPG project. There was once an instance where someone thought that my criticism meant that I supported the 9580 faction. It got awkward... :)
I am quite critical of the GnuPG project on this point in my article about the schism:
https://articles.59.ca/doku.php?id=pgpfan:schism#where_are_we_now
@upofadown Ahh, I see. Sorry, I am not subscribed to gnupg-users, and didn't think to look there.
At first glance, it looks to me like your (reasonably) raised concern was brushed off.
As much as I wish this were not the case, I have arrived at the conclusion that there is just no way to collaborate with GnuPG. It seems to be very much a "take it or leave it" arrangement.
Given just these two options, I know what I'm picking.
@upofadown Working on minipgp6 (as a suite of software that explicitly does NOT contain any compatibility with v4 or earlier formats) is going to be an experiment at entirely sidestepping the uncomfortable gray areas of the schism - and only engaging with other implementations that support v6 formats.
In other projects I'll continue to engage with those gray areas, though - and I welcome constructive input with the goal of limiting pain for all inhabitants of the OpenPGP ecosystem.
@upofadown However, to be very clear: I don't consider "stop doing RFC 9580" constructive.
We need to move forward. And "LibrePGP", in my opinion, is not a serious path forward.
> My understanding is that GCM is a significant point of contention in the OpenPGP standards schism.
I can see how one might reasonably get that impression. However, I believe the available evidence does show that the impression does not line up with the material reality of the debates.
(Regarding performance: GCM is supported by Web Crypto, OCB is currently not.)
Heiko
Bruce Walzer 🇨🇦
Clemens