Post-Quantum OpenPGP Arrives: RFC 9980, the GnuPG Split, and the Signature Gap

June 30, 2026 — In June 2026, the Internet Engineering Task Force (IETF) published RFC 9980, a Proposed Standard titled “Post-Quantum Cryptography in OpenPGP.” The document defines quantum-resistant public-key encryption and digital signatures for the OpenPGP message format, extending RFC 9580, the 2024 revision of the protocol. It is the post-quantum OpenPGP extension the working group has been building since mid-2022, and it draws entirely on algorithms from NIST’s post-quantum standardization: ML-KEM (formerly CRYSTALS-Kyber) for encryption, ML-DSA (formerly CRYSTALS-Dilithium) for signatures, and SLH-DSA (formerly SPHINCS+) as a standalone signature option.

The specification was written by Stavros Kousidis of Germany’s Federal Office for Information Security (BSI), Johannes Roth and Falko Strenzke of the German cryptography firm MTG AG, and Aron Wussler of Proton AG. It began as an individual submission in 2022, weeks after NIST announced its algorithm selections, and passed through 17 working-group revisions before the IESG approved it for publication.

For organizations that still run OpenPGP anywhere in their stack—and far more do than realize it, in encrypted backups, batch file transfers, secrets tooling, and the signature checks behind every Linux package install—the reference design for quantum-resistant OpenPGP now exists as a published standard. Whether the tools in their pipelines implement that standard, or a rival one, is now the operative question.

RFC 9980 defines two composite encryption algorithms: ML-KEM-768 combined with X25519, which every implementation must support, and ML-KEM-1024 combined with X448, which implementations should support. On the signature side, ML-DSA-65 combined with Ed25519 is mandatory, and ML-DSA-87 combined with Ed448 is recommended. Three parameter sets of the hash-based SLH-DSA (SHAKE-128s, SHAKE-128f, and SHAKE-256s) are optional. The lattice-based algorithms never appear alone. Every ML-KEM encryption and every ML-DSA signature is a composite operation with an elliptic-curve counterpart, and a message only decrypts, or a signature only verifies, if every component operation succeeds. SLH-DSA is the single algorithm the standard permits standalone, on the grounds that the security assumptions behind hash-based signatures are mature enough to carry the load alone.

The composite encryption scheme binds its two shared secrets with a key combiner modeled on the X-Wing hybrid key encapsulation mechanism (KEM); the combiner folds the ciphertexts and public keys into the key derivation so that components from different messages cannot be mixed and matched. Messages encrypted to the new algorithms must use AES-256 inside OpenPGP’s modern authenticated-encryption packet format. With one exception, all of the new algorithms require version 6 (v6) keys, the key format RFC 9580 introduced. The exception: ML-KEM-768 with X25519 may also be carried on version 4 (v4) encryption subkeys, the format the pre-2024 OpenPGP installed base runs on.

Publication lands in the middle of a transition in the OpenPGP tooling world. GnuPG, the most widely deployed implementation, shipped composite Kyber+ECC support in version 2.5.0 on July 5, 2024, labeled experimental because FIPS 203 had not been finalized when the code was written. Last week the project released version 2.5.21 and declared the 2.4 series end-of-life; the 2.6 stable series that carries the Kyber work is next. GnuPG, however, does not implement RFC 9580 or RFC 9980. Since late 2023 it has followed LibrePGP, a rival specification GnuPG founder Werner Koch created after breaking with the IETF working group over the RFC 9580 format changes, with the RNP library (the OpenPGP engine inside Thunderbird) and Gpg4win backing the fork. Proton, whose cryptographers co-authored RFC 9980, committed in October 2023 to deploying hybrid post-quantum encryption across its OpenPGP libraries.

My Analysis

A format whose ciphertext outlives everything else

A TLS session key protects traffic for milliseconds and is gone. An OpenPGP-encrypted file is designed to sit on a disk, a tape, or a stranger’s server for decades and still open. That design goal is why I consider OpenPGP one of the highest-exposure targets of the Harvest Now, Decrypt Later threat: an adversary who copies a .gpg archive today needs no exploit, only storage and patience, until a cryptographically relevant quantum computer (CRQC) can run Shor’s algorithm against the RSA or elliptic-curve key that wrapped the session key.

The exposure math differs from the web’s. A quantum-vulnerable TLS handshake recorded in 2019 guards traffic that mostly lost its value years ago. A quantum-vulnerable OpenPGP archive from 2019 may guard trade secrets, source code escrow, or legal records with a 30-year confidentiality requirement. OpenPGP needed a post-quantum answer more urgently than most protocols, and it got one later than most. TLS, SSH, and Signal all deployed hybrid key establishment before the OpenPGP RFC existed.

OpenPGP’s 2026 footprint turns that horizon problem into an enterprise matter. The protocol sits inside managed file-transfer products moving payment batches between banks, inside backup pipelines at firms that standardized on gpg-wrapped tarballs 15 years ago, and inside vendor onboarding documents that still specify “PGP-encrypt the SFTP drop.” Much of it was deployed by people who have since left, which is why cryptographic inventories keep finding OpenPGP in places nobody remembered owning. Each of those integrations produces ciphertext with a shelf life, and until last month there was no standardized way to produce it quantum-resistantly.

What post-quantum OpenPGP gets right

The design decisions in RFC 9980 are conservative, and for this format conservative is correct. I spent early June arguing that the biggest near-term risk in PQC migration is implementation failure, not quantum computers, and that hybrid constructions are cheap insurance against it. OpenPGP strengthens that case beyond what I argued for TLS and code signing, because OpenPGP has no negotiation and no rapid rotation. A browser vendor can retire a broken algorithm fleet-wide in a six-week release cycle. An OpenPGP key propagates by keyserver, by email signature block, and by being baked into a CI container in 2021; the ciphertexts and signatures it produces persist indefinitely.

So consider the failure case. NIST’s own process watched SIKE fall to a classical attack in about an hour on a single core, and Rainbow to a laptop, both in 2022. If a comparable result ever lands on module lattices, a composite OpenPGP ciphertext degrades to classical ECC strength. A pure ML-KEM ciphertext falls open. The price of that insurance is close to a rounding error at OpenPGP’s sizes: X25519 adds 32-byte key material to ML-KEM-768’s 1,088-byte ciphertexts, and an Ed25519 layer adds 64 bytes to ML-DSA-65’s 3,309-byte signatures. A tax of 2 to 3 percent buys a complete classical fallback.

The composition logic favors the defender. RFC 9980’s composites are AND-constructions: a forger must defeat both ML-DSA and Ed25519 to fake one signature, and an eavesdropper must break both ML-KEM and X25519 to recover one message key. The recipient, in turn, must check every component, since the standard rejects any message where either half fails. That rule closes the downgrade path in which an attacker strips the stronger component and presents the weaker one alone, a failure pattern that has burned deployed cryptography repeatedly. The working group wrote component verification as a hard requirement rather than an implementer’s option, which is exactly where schemes like this usually go wrong.

Several national authorities are steering toward pure post-quantum deployments as the end state, and for online, negotiable protocols that position is defensible. For a store-and-open-forever format, I think the working group chose the right lane, and I would say the same about permitting standalone SLH-DSA. Hash-based signatures rest on assumptions cryptanalysts have battered for four decades without much movement, which makes SLH-DSA the sensible option for roots of trust that must hold for 20 years, provided the operator can live with signatures over 7 KB.

One design consequence will surprise administrators: there is no RSA composite. The classical component of every new algorithm is a Curve25519 or Curve448 primitive, so the enormous installed base of RSA keys has no upgrade path inside RFC 9980. Going quantum-resistant means minting new key material, either fresh v6 certificates or new subkeys, and re-encrypting or re-signing forward from there. For planning purposes, treat this as a key-generation and distribution project, and budget for the certificate-exchange logistics that OpenPGP, with no PKI to lean on, pushes onto operators themselves.

One carve-out carries the politics

The v4 exception for ML-KEM-768+X25519 is three sentences of the specification and the entire OpenPGP power struggle in miniature. RFC 9580 introduced v6 keys, and GnuPG refused to follow. In late 2023, Werner Koch forked the specification into LibrePGP rather than accept the IETF revision, taking Gpg4win and the RNP library with him, and the world’s largest OpenPGP installed base has sat outside the IETF process since. Requiring v6 keys for all post-quantum algorithms would have made quantum-resistant encryption unreachable for that installed base until a key-format migration nobody has scheduled. The carve-out is the working group conceding that harvest exposure will not wait for standards politics to resolve.

Whether the concession actually buys interoperability is the question I cannot yet answer with a demonstration. GnuPG’s Kyber implementation descends from the same composite design as the IETF draft; Koch credited the RFC’s authors when he published the LibrePGP KEM specification in May 2024 and described the algorithms as “the same except for the fixed info”. In a KEM combiner, the fixed info is the context string mixed into the key derivation. If the two specifications feed different context strings into the derivation, identical primitives produce different message keys, and decryption fails across camps even though both sides run ML-KEM-768 with X25519. Same mathematics, mutually unreadable messages. Add the packet-level divergences, including LibrePGP’s Brainpool composite variants that RFC 9980 does not define, and my working assumption is that cross-camp decryption is unproven until someone shows me a GnuPG-encrypted message opening in an RFC 9980 stack. I intend to run that test.

Two PGPs, one installed base

The camps are now easy to draw. On the RFC 9980 side: Proton’s GopenPGP and OpenPGP.js, which sit behind Proton Mail’s tens of millions of accounts, and Sequoia, the Rust implementation Fedora already uses for RPM signature verification. On the LibrePGP side: GnuPG and Gpg4win, which between them handle the majority of command-line, server-side, and Windows OpenPGP work, plus RNP, which leaves Thunderbird strung between an IETF-aligned product direction and a fork-aligned crypto engine.

An enterprise does not get to pick one camp. Its managed file-transfer appliance embeds one library, its email plugin another, its CI signing container a third, and none of those vendors asked. The failure modes are concrete: a v6 post-quantum certificate that GnuPG declines to import, a GnuPG Kyber subkey that a strict RFC 9980 implementation declines to encrypt to, a compliance requirement for quantum-resistant encryption that two connected parties satisfy with incompatible dialects.

Distribution mechanics will pick the default winner in each niche, and the mechanics differ by niche. Server-side automation and Linux packaging inherit whatever GnuPG ships, because gpg is already on the box; hundreds of thousands of cron jobs become LibrePGP-dialect PQC the day a distribution moves to GnuPG 2.6, with no administrator deciding anything. Webmail and consumer messaging inherit the RFC 9980 dialect the same way, through Proton’s libraries and OpenPGP.js updating underneath their users. Most exposed to the seam are the organizations in between: enterprises whose compliance teams will discover, at audit time, that “we use post-quantum PGP” is true on both sides of a file transfer that fails.

OpenPGP has survived schisms before. The PGP 2.x versus PGP 5 era fractured the format in the 1990s until RFC 2440 and later RFC 4880 gave every implementer a single target, and the format’s entire value proposition since has been that a file encrypted anywhere opens anywhere, forever. Two post-quantum dialects tax exactly that property, at exactly the layer where quantum exposure is worst. An organization that encrypts a 20-year archive in the wrong dialect has manufactured a readability problem for itself before any quantum computer manufactures a confidentiality one. The working group did the pragmatic thing available to a standards body; from here, convergence depends on implementers deciding their users matter more than the feud.

Signatures are where OpenPGP still runs the world

Encrypted email over PGP is a minority sport in 2026, even among people who write cryptography for a living. OpenPGP signatures are something else entirely: invisible, load-bearing infrastructure. Every apt update verifies repository metadata through GnuPG tooling on hundreds of millions of Debian and Ubuntu systems. Release tarballs, firmware bundles, Maven artifacts, and Linux ISOs ship under OpenPGP signatures. This is the exposure I named Trust Now, Forge Later: an adversary who archives public keys today and derives the private keys with a CRQC can mint signatures on packages and updates that appear to have existed all along. Where harvest-now-decrypt-later threatens yesterday’s ciphertext, the signature problem threatens tomorrow’s trust in yesterday’s software.

The verification horizon makes the arithmetic uncomfortable. A signing key minted in 2026 validates artifacts for as long as the artifacts live, and Ubuntu and Red Hat support LTS releases for 10 to 12 years, with appliances and industrial systems built on them running longer still. Signatures created this year must stay unforgeable into the late 2030s, on classical Ed25519 and RSA keys whose public halves are, by design, published everywhere. That is a long bet on the elliptic-curve discrete logarithm problem, placed on behalf of every system that will ever run apt-get upgrade against today’s keys.

RFC 9980’s answer is sound. Composite ML-DSA-65+Ed25519 is mandatory, and SLH-DSA is available for operators who want hash-based conservatism at the root of trust. The gap is on the other side of the split: the new signature algorithms require v6 keys with no v4 carve-out, and GnuPG, the engine inside most of the world’s package verification, currently has no post-quantum signature support at all. Koch has been open about the ordering; in the same May 2024 note, he wrote that quantum-resistant signature schemes are a far lower priority than encryption and need more real-world experience before deployment.

Assessed on the evidence, that ordering has a defensible core. Confidentiality breaks retroactively; signature forgery only becomes possible once a CRQC exists, and revocation plus re-signing offers a partial remedy that decryption has no analog for. But partial is carrying a lot of weight in that sentence. Trust anchors ship baked into OS images and appliance firmware that will never be re-flashed. Re-signing decades of artifacts presumes you notice Q-Day when it happens. NSA’s CNSA 2.0 put software and firmware signing first on its transition schedule for precisely this reason: signed code has the longest deployment tail of anything in the estate. Deferring signature migration is a legitimate engineering position only when it comes with a date attached, and the LibrePGP camp has not published one.

What to do with a PGP estate

If OpenPGP appears anywhere in your environment, the work ahead splits into a few concrete moves:

• Find it first. OpenPGP hides in batch file-transfer jobs, backup encryption, secrets tooling, and vendor SFTP requirements written in 2009. Discovery is the first gate of the PQC Migration Framework for a reason, and the practical first steps apply here unchanged.
• Triage archives by confidentiality horizon. Anything under RSA or ECC keys with a decade-plus requirement is standing harvest exposure. Wrap the data-encryption keys under a composite ML-KEM key rather than re-encrypting petabytes in place, the approach I detailed in Mitigating Quantum Threats Beyond PQC.
• Choose a dialect per pipeline, deliberately. A homogeneous GnuPG estate can generate Kyber subkeys today and enforce them with --require-pqc-encryption. Any flow that crosses camps needs a decrypt test in both directions before a single archive depends on it.
• Watch the signature seam. If you sign software with long verification horizons, get your toolchain’s RFC 9980 timeline in writing, and evaluate SLH-DSA v6 keys for new roots of trust where the tooling follows the standard. Build the swap capability regardless; crypto-agility is what turns an algorithm break into a changeover instead of a crisis.
• Do not wait for the camps to reconcile. The encryption side is deployable now within one dialect, and harvest exposure accrues daily. Interoperability perfection is not a precondition for protecting new archives.

OpenPGP has outlived every obituary written for it because the things it protects outlive everything else. RFC 9980 is the format finally engineering for that longevity rather than merely trading on it, and half of the fix is now published. The other half, two implementation camps agreeing to read each other’s quantum-resistant messages, has no RFC, and no working group can write one.