jxself.org

The OpenPGP Schism

Sun, 23 Nov 2025

I was looking into post-quantum cryptography (PQC) support in GnuPG, eager to see how we prepare our digital identities for "Q-Day." What I found, however, wasn't a unified front, but a present-day civil war over standards.

We need to talk about the state of OpenPGP because divergent standards threaten the very foundation of our digital security, risking fragmentation that could undermine trust and interoperability.

For over two decades, the interoperability of encrypted email and file signing relied on a unified specification - RFC 4880 - which defined the "Version 4" (v4) key format. The "friend" we relied on has split into two personalities, and I'm deeply disappointed to report that they're no longer speaking to each other.

We're facing a hard fork between two competing visions for the future: LibrePGP (v5), championed by GnuPG, and RFC 9580 (v6), the official IETF standard supported by Sequoia PGP.

While technical disagreements happen in free software, the emphasis on a "clean break" in the IETF RFC 9580 (v6) standard and the Sequoia PGP team's approach risks damaging our digital identities by prioritizing 'crypto-agility' over continuity.

On paper, a clean break sounds efficient. In reality, it's a scorched-earth policy for our digital identities.

By mandating a hard shift to v6, the IETF standard effectively declares that our existing Web of Trust is "legacy debt" to be discarded. If you move to a v6 key, you lose the signatures on your key. All those key-signing parties, the decades of social trust verification, and the intricate map of connections we've built - it all evaporates.

The proponents of RFC 9580 seem to believe that this is a reasonable price to pay for a tidier packet format. I disagree. Asking the entire world to reset its digital reputation to zero to advance post-quantum crypto is a bit much and ignores the human cost of security.

GnuPG's approach (v5), attempts to preserve these structures. It recognizes that our keys aren't just mathematical objects; they're histories of trust.

To show why this philosophical split causes practical issues, consider our favorite hypothetical users, Alice and Bob, who both want to upgrade to PQC algorithms to protect their emails from 'harvest now, decrypt later' attacks.

The Setup:

  1. Alice is a GnuPG user. She generates a new post-quantum key. GnuPG, following the LibrePGP spec, creates a Version 5 (v5) key.

  2. Bob uses Sequoia PGP. He also generates a post-quantum key. His software, in accordance with RFC 9580, creates a Version 6 (v6) key.

The Failure:

  1. Alice sends her public key to Bob. Bob's software parses the file and throws an error. It sees a "Version 5" packet, which is not part of RFC 9580. It effectively treats Alice's key as corrupt or unsupported junk data.

  2. Bob sends his key to Alice. Alice tries to import Bob's key. It encounters a "Version 6" packet. GnuPG refuses to use it because it considers the IETF spec deficient.

The result? Alice and Bob can't communicate securely using modern crypto. They're forced to downgrade to older algorithms or give up.

Despite this chaos, I wanted to get PQC working today without waiting for the dust to settle. I'm currently running Trisquel 11 (Aramo).

The default repositories for Trisquel (based on Ubuntu 22.04) carry an older version of GnuPG that predates this PQC work. However, the GnuPG team has made it surprisingly easy to jump the queue.

I followed the instructions from the GnuPG blog. By adding their signed repository to my sources, I was able to pull in the modern GnuPG (v2.5.13 at present) with full support for PQC algorithms.

It worked. I generated a post-quantum key on an entirely free operating system. The beauty of doing this via GnuPG is that it felt like an evolution of my existing setup, not a demolition of it. I didn't have to throw away my identity to get future-proof encryption. You can find my updated public key with post-quantum crypto at https://jxself.org/gpg.shtml, which uses a hybrid Kyber 1024 (X448).

It's not a "perfect" end-state (where everything is PQC), but it's the most practical posture for now. It blocks the surveillance dragnet (harvest now, decrypt later) while keeping the Web of Trust intact.

Unless these standards reconcile, we face a future where users are divided with incompatible tools, leading to widespread security and usability issues.

  • Distro Maintainers: Will distros ship GnuPG (v5) or Sequoia PGP (v6) as the default provider, knowing that whatever they pick will be incompatible with the other half of the world?

  • Keyservers: The global keyserver network is already struggling; how will it handle two competing, incompatible identity formats?

Users face the most significant risk: Losing seamless, secure communication as incompatible standards threaten to fragment our digital trust infrastructure. Since the people behind these projects can't agree, the burden falls on us. We may be forced to adopt a dual-stack identity strategy to maintain both an IETF-compliant and a LibrePGP-compliant PQC key.

It's clumsy. It's redundant. It's the antithesis of the "universal" encryption standard we were promised. But if we want to use post-quantum cryptography today, we might have to carry two keys because the standards body decided that "clean code" was more important than our Web of Trust.

I'm not angry; I'm disappointed. We had the opportunity to secure the future together, but instead, we built two separate locked doors.