Post-quantum OpenPGP, and the schism.

Two things happened to OpenPGP in the 2020s. It got a credible post-quantum story — RFC 9980, published June 2026, specifying composite ML-KEM+ECDH encryption, composite ML-DSA+EdDSA signatures, and standalone SLH-DSA. And it split into two incompatible standards, with GnuPG pursuing LibrePGP and the IETF working group and Sequoia pursuing RFC 9580. This article covers the cryptographic constructions in detail — including why hybrid rather than pure PQC, and what a KEM combiner must actually bind — then treats the schism as the concrete interoperability problem it is, and ends with an implementation comparison for people who have to choose a library.

1. The threat model, stated precisely

A cryptographically relevant quantum computer running Shor's algorithm breaks RSA, DSA, and every elliptic-curve scheme OpenPGP currently uses. No such machine is known to exist. The reason to act now is harvest-now-decrypt-later: an adversary who records ciphertext today and stores it can decrypt it whenever such a machine arrives.

This threat is unusually severe for OpenPGP specifically. Email and file encryption produce artifacts with very long confidentiality requirements — archives, legal documents, journalistic source material, medical records. A TLS session key protects data for the lifetime of the connection; an encrypted archive may need to stay confidential for decades.

2. Why hybrid, not pure post-quantum

RFC 9980 does not replace ECC. It combines ECC and PQC, so that the construction stays secure if either component survives. The reasoning is explicit in the RFC: deploy post-quantum in combination with traditional schemes such that security is retained even if all schemes but one in the combination are broken.

Concern	Pure PQC	Hybrid
Classical cryptanalysis of new lattice assumptions	Total loss if broken	Falls back to ECC security
Implementation bugs in new, less-exercised code	Total loss	ECC path still holds
Quantum adversary	Secure	Secure (PQ component holds)
Key and ciphertext size	Large	Larger
Compute cost	Moderate	Both operations

The lattice assumptions underlying ML-KEM and ML-DSA are roughly a decade old in their current form and have had far less cryptanalytic attention than RSA or the discrete log problem. Hybrid is the conservative response to that asymmetry in scrutiny, not a hedge against NIST's judgment.

3. Composite encryption: ML-KEM + ECDH

RFC 9980 defines two composite encryption algorithms:

Algorithm	Components	Requirement level
ML-KEM-768 + X25519	NIST security category 3 + Curve25519	MUST implement
ML-KEM-1024 + X448	NIST security category 5 + Curve448	SHOULD implement

3.1 The KEM combiner

Both KEMs are run independently, producing two shared secrets, which are then combined through a KDF into the key that actually wraps the session key:

The binding requirement is the subtle part and worth stating explicitly. A naive combiner \(K = \text{KDF}(ss_{pq} \| ss_{ecc})\) is not robust: it fails to bind the derived key to the specific ciphertexts and public keys involved, which opens the door to re-encapsulation and key-substitution attacks where an adversary swaps one component's ciphertext for one of their own. RFC 9980's combiner includes both ciphertexts, both public keys, and a domain-separation label, which is what makes the composition secure rather than merely convenient.

3.2 Size consequences

Quantity	X25519 alone	ML-KEM-768 + X25519
Public key	32 B	~1,216 B
Ciphertext / PKESK payload	32 B	~1,120 B
Private key	32 B	~2,432 B

Roughly a 35× growth in key size. For most OpenPGP use this is irrelevant — a 1 KB PKESK on a 50 KB email is noise. It matters in three places: constrained hardware tokens (many smartcards cannot store keys this size), keyserver and WKD storage and bandwidth at scale, and any protocol that embeds OpenPGP certificates in size-limited fields — DNS records for DANE being the obvious casualty.

4. Post-quantum signatures

4.1 Composite ML-DSA + EdDSA

Signatures follow the same hybrid pattern: both signatures are computed over the same message and both must verify. RFC 9980 defines composites pairing ML-DSA-65 with Ed25519 and ML-DSA-87 with Ed448.

\[ \text{verify}(m, \sigma) = \text{verify}_{\text{ML-DSA}}(m, \sigma_{pq}) \ \land \ \text{verify}_{\text{EdDSA}}(m, \sigma_{ecc}) \]

The conjunction matters. An implementation that accepts the signature if either component verifies has built a downgrade: an attacker who breaks one component can forge freely. Both, always, or reject.

4.2 SLH-DSA standalone

SLH-DSA (formerly SPHINCS+) is included as a standalone algorithm rather than as a hybrid component, and the reason is structural: it is hash-based, so its security rests only on the hash function's properties rather than on lattice assumptions. There is no need to hedge it with ECC, because its assumptions are the most conservative available.

The cost is size. SLH-DSA signatures are large — on the order of 8–30 KB depending on parameter set, versus 64 bytes for Ed25519. That makes it unsuitable for routine message signing and well-suited to exactly one thing: long-lived root and code-signing keys, where signature size is irrelevant and the strongest possible assumption is worth paying for.

Use case	Recommended	Why
Routine message signing	ML-DSA-65 + Ed25519	Reasonable size, hybrid safety
Software release signing	SLH-DSA, or composite	Verified rarely, must last decades
Long-lived offline root key	SLH-DSA	Most conservative assumptions available
Encryption subkey	ML-KEM-768 + X25519	MTI, harvest-now-decrypt-later urgency

5. The schism

This section is factual rather than partisan. Both sides have coherent positions; the consequence for you is an interoperability matrix you must plan around.

5.1 What happened

The OpenPGP working group spent years revising RFC 4880. In September 2022, GnuPG announced it would implement an earlier draft rather than the direction the rest of the working group had agreed. The working group continued and published RFC 9580 in July 2024, defining version 6 keys, SEIPDv2, and the AEAD design covered in Articles 2 and 3. GnuPG and allied implementers formalized their alternative as LibrePGP, based on the v5 design.

Werner Koch's stated position is that the IETF's changes were harmful to existing deployments and that users need long-term stability over disruptive change. The working group's position, as described in LWN's coverage, is that the changes were substantive security improvements: protection against key-overwriting attacks, a wire-format change to prevent signature aliasing, and downgrade protection.

5.2 The technical disagreements

Area	RFC 9580	LibrePGP	Consequence
AEAD container	SEIPD version 2 (tag 18)	AEAD Encrypted Data, tag 20	Ciphertext does not decrypt across implementations
Key version	v6 — SHA-256 fingerprints, explicit lengths, salted sigs	v5 — different layout and fingerprint construction	Certificates are not mutually parseable
Chunking	Exponent-based chunk sizes in SEIPDv2	Different chunking scheme	Even where both do AEAD, framing differs
Secret-key AEAD binding	AD binds the public key packet	Different construction	The key-overwriting protection differs
Signature salting	v6 signatures salted	Not adopted	Different collision-resistance posture

5.3 A defensible engineering posture

Given the split, the interoperability-maximizing configuration for general correspondence in 2026 is unglamorous:

• v4 keys with Ed25519 signing and X25519 encryption subkeys — parsed by everything.
• SEIPDv1 with a correctly-enforced MDC for messages to unknown peers, per Article 3's strict-rejection rules.
• SEIPDv2 AEAD where you know the peer speaks RFC 9580.
• v6 keys and post-quantum algorithms where you control both ends — internal systems, machine-to-machine, archival encryption with a known toolchain.

For archival encryption specifically, the harvest-now-decrypt-later argument overrides interoperability: if you are encrypting something that must stay confidential for twenty years and you control the decryption side, use ML-KEM-768+X25519 now.

6. The implementation landscape

Implementation	Language	Standard	Interface	Notes
GnuPG	C	RFC 4880 + LibrePGP	CLI, plus GPGME	The reference deployment. CLI-parsing integrations carry the SigSpoof bug class (Article 4).
Sequoia	Rust	RFC 9580	Library-first; sq CLI	Memory-safe, independently audited, strict policy engine. The reference for new work.
RNP	C++	RFC 4880 + AEAD	Library	Used by Thunderbird. C++ memory-safety caveats apply.
OpenPGP.js	JavaScript	RFC 4880 + parts of 9580	Library	Browser/Node. Memory-safe runtime; see CVE-2025-47934 for API-shape hazards.
GopenPGP	Go	RFC 4880 + extensions	Library	Proton's native-app stack; wraps Go's crypto/openpgp lineage.

6.1 Memory safety is not a slogan here

An OpenPGP implementation parses attacker-controlled, deeply-nested, variably-length binary from untrusted sources — the archetypal environment for memory-corruption bugs. Rust and Go eliminate buffer overflows and use-after-free by construction; C and C++ do not. That is a genuine, measurable difference in attack surface for this specific workload, independent of any team's competence.

Memory safety is not sufficient, though, and OpenPGP.js's CVE-2025-47934 makes the point: message-spoofing through an API-shape confusion, in a memory-safe language. Logic bugs in verification interfaces survive any language choice.

6.2 Choosing a library

7. A migration plan

Phase	Action	Rationale
1 — Inventory	Enumerate keys, algorithms, key versions, and which implementation each consumer uses	You cannot plan a migration you cannot describe
2 — Retire the indefensible	Remove RSA <3072, DSA, Elgamal, SED (tag 9) acceptance, S2K usage 255	These are weak today, independent of quantum concerns
3 — Modernize classically	Ed25519 + X25519, SEIPDv2 where peers allow, Argon2-protected secret keys	Best available classical posture; prerequisite for the rest
4 — Hybrid PQC where you control both ends	ML-KEM-768+X25519 encryption subkeys for archival and internal use	Harvest-now-decrypt-later is the live threat
5 — PQC signatures for long-lived roots	SLH-DSA for offline roots and release signing	Size is irrelevant there; assumption strength is not
6 — Instrument	Log algorithm and version usage across your fleet	Migration progress is unmeasurable otherwise

FAQ

Should I move to post-quantum OpenPGP now?

For encryption of long-lived data where you control decryption, yes — harvest-now-decrypt-later means waiting has a real cost that arrives retroactively. For general correspondence, not yet; interoperability is poor and the classical algorithms are not broken. For signatures, there is no urgency, because forgery cannot be applied retroactively to already-verified signatures.

Is hybrid just hedging against NIST?

It is hedging against cryptanalytic immaturity, which is a different and more defensible claim. The lattice assumptions are far less studied than RSA or discrete log, and the implementations are new. Hybrid means a break in either the assumption or the implementation is survivable. The cost is size and compute, both of which OpenPGP can afford.

Which side of the schism should I build on?

If you control both ends: RFC 9580, via Sequoia. It is the IETF standard, it has the better security properties discussed in Articles 2 and 3, and it is where the post-quantum work landed. If you must interoperate with the installed GnuPG base: support v4 keys and SEIPDv1 as your baseline, and treat v6/SEIPDv2 as an opportunistic upgrade. Do not build a system that assumes one dialect is universal.

Why is SLH-DSA standalone rather than hybrid?

Its security rests on hash function properties alone — the most conservative assumption in the entire toolkit, and one that has survived far more scrutiny than lattices. Adding ECC would increase size and complexity to hedge against an assumption that does not need hedging.

Takeaways

• Harvest-now-decrypt-later makes encryption migration urgent and signature migration not. The asymmetry should drive your prioritization.
• A KEM combiner must bind ciphertexts and public keys, not merely concatenate shared secrets, or the composition loses the robustness that is the whole point of going hybrid.
• Composite signature verification is a conjunction. Accepting either component is a built-in downgrade.
• SLH-DSA is for roots, not for messages — 8–30 KB signatures are fine on a key you verify once a year.
• The schism is concrete, not political: tag 18 v2 versus tag 20 means ciphertext that does not decrypt. Specify your dialect explicitly.
• Memory safety materially reduces attack surface for this workload, but does not touch the verification-interface bug class that has caused the most damage.

Next in this series

Article 7 — The complete resource map: every RFC, research paper, book, video, course, tool, and mailing list worth your time, plus a structured learning roadmap for implementers and researchers.

References

• RFC 9980 — Post-Quantum Cryptography in OpenPGP — Proposed Standard, June 2026. Composite ML-KEM/ML-DSA constructions, SLH-DSA, and the combiner definition.
• draft-ietf-openpgp-pqc — working group history — the draft series behind RFC 9980; useful for design rationale the RFC compresses.
• RFC 9580 — OpenPGP — the standard LibrePGP diverges from.
• LibrePGP specification — the other side of the split, in its own words.
• LWN — A schism in the OpenPGP world — the most balanced account of the disagreement and its origins.
• GnuPG — thoughts on Sequoia and LibrePGP — the GnuPG-side position, worth reading directly rather than through summaries.
• Sequoia — on the standardization situation — the RFC 9580-side position.
• FIPS 203 — ML-KEM — the underlying KEM standard.
• FIPS 204 — ML-DSA — the underlying signature standard.
• FIPS 205 — SLH-DSA — the hash-based signature standard.