A schism in the OpenPGP world

Privacy
1

Last year, a schism in OpenPGP became apparent.

The OpenPGP standard for email encryption has been around since 1997, when it was derived from the venerable Pretty Good Privacy (PGP) program that was released in 1991. Since it came about, OpenPGP has been the decentralized, interoperable way to exchange encrypted email, though its use never really took off as advocates hoped. Now, though, it would seem that a split in the OpenPGP community threatens to fragment the OpenPGP-encrypted-email landscape, potentially leading to interoperability woes.

Currently there are two competing standards.

To boil it down to one sentence, it looks like LibrePGP desires incremental changes to OpenPGP to avoid breaking compatibility, while crypto refresh desires major changes for security reasons. However, this is very simplified, so I encourage interested people to read the standards and explanations linked above.

I see a few ways for how this schism could get resolved, but cannot predict what will happen. While this schism exists, I see there are risks of OpenPGP fragmentation and interoperability issues. This could affect not just E2EE emails but also data encryption generally, cryptographic signing and other cryptographic operations that OpenPGP supports.

  • Which standard is best (technically or otherwise) for OpenPGP users and the future of OpenPGP?
  • What should OpenPGP users (end users, application developers, etc) do while this schism exists?
1 Like
2

What are the most important players like Protonmail, Thunderbird, Mailvelope and OpenKeyChain using?

1 Like
3

All of those aren’t using the same exact same thing.

4

Most likely most downstreams have not yet substantially adopted either standard. Below is what I found after a brief search through the above sources, project webpages and other sources.

  • Proton Mail: involved in crypto refresh; uses and maintains OpenPGP.js
  • Thunderbird: uses RNP but is freezing implementation of new OpenPGP features
  • Mailvelope: ?
  • OpenKeychain: ?
  • GnuPG: involved in LibrePGP
  • Hockeypuck: the draft standard for OpenPGP keyservers has some support for v6 keys but imposes limits in consideration of clients that do not support v6 keys
  • keys.openpgp.org: its governance board includes people from Proton and Sequoia
  • OpenPGP.js: supports crypto refresh; maintained by Proton Mail
  • RNP: openly supports LibrePGP
  • Sequoia PGP: involved in crypto refresh

I found this article by a keyserver operator that discusses technical differences, describes the conflict as personal rather than technical, and proposes a way forward that hopes to achieve harmony between v5 and v6.

Yes, some implementations do their own quirky things, others simply don’t implement OpenPGP in full.

1 Like
5

Seems like the X11/Wayland argument to me. In the long run, the correct way forward is to do it the right way rather than supporting all fringe use cases.

6

Does anyone have any coherent idea of what is currently happening with this situation? The drama seemingly continues but RFC 9580 (the ‘crypto-refresh’) appears to be moving forwards regardless.

Here is my understanding:

RFC 9580 became a proposed standard in July of 2024

OpenPGP.js v6 added support for RFC 9580 in November of 2024

Sequoia PGP v2 added support for RFC 9580 in March of 2025

For RFC 9580 to be promoted to a draft standard requires “two independent and interoperable implementations from different code bases” which appears to be the case as of March 2025.

1 Like
7

In internal discussions the consensus is clear: They are leaving Gnu behind, hoping their transition forces Gnu to change their stance.

Ecosystem will not change much, crypto refresh evangelists still support the older systems.

2 Likes