GnuPG 2.5.19 lands ML-KEM in mainline. Post-quantum OpenPGP is no longer a side branch.

Werner Koch announced GnuPG 2.5.19 on the gnupg-announce list on April 24, and the headline feature is the one OpenPGP users have been waiting on for years: ML-KEM, the standardized version of Kyber, now ships as a usable encryption algorithm in the development branch. The 2.4 stable line goes end-of-life in two months. Post-quantum OpenPGP just stopped being a side experiment.

What’s actually in 2.5.19

• ML-KEM lands as PQC encryption. The release notes call out Kyber, “aka ML-KEM or FIPS-203,” as the post-quantum encryption algorithm for the 2.5 series. That’s the standardized version NIST finalized in 2024. Until now, working with Kyber in GnuPG meant patching against an experimental branch. Now it’s part of the mainline tree the rest of 2.5.x is built on.
• The 2.5 line is the runway for 2.6. Koch calls 2.5 a development series with internal-only changes, and 2.6 the next major. The 2.4 stable series sunsets in two months. So 2.5.19 isn’t what most people will deploy, but it’s a clear preview of what 2.6 will ship as default.
• Other 2.5.19 polish. A new --use-ocb-sym symmetric-mode option, session hash display, smartcard pinentry fixes, RSA SSH padding corrections, trustlist file handling, and tighter de-vs compliance checking. Useful, mostly invisible to end users.
• The library stack is moving with it. Libgcrypt has carried Kyber primitives for a release or two; what 2.5.19 does is wire them through the OpenPGP layer so gpg --encrypt can actually use them once you have a PQ key.

What it doesn’t include

The release does not include post-quantum signatures. The IETF draft-ietf-openpgp-pqc revision 17 spec covers both encryption (ML-KEM hybrids) and signatures (ML-DSA / SLH-DSA), but only the encryption side is interoperable enough to ship now. ML-DSA and SLH-DSA are still in flux. So a 2.5.19 user can encrypt with a PQ-hybrid key, but signatures stay on classical Ed25519/RSA until the spec settles and other implementations follow.

That’s the gap that matters most to the 70-organization PGP ecosystem. Encryption you can roll out unilaterally; the recipient just needs a current GnuPG. Signatures need the verifier’s tooling to understand the new algorithm too, and the verifier ecosystem moves slowly.

Why this matters now, not in 2029

Google’s security team pulled “Q-Day” into 2029 in March, six years earlier than the NSA’s prior 2031 estimate. That’s the public end of the runway for current asymmetric crypto. Even if Q-Day lands on schedule, the relevant deadline isn’t when the first quantum computer breaks RSA: it’s when “harvest now, decrypt later” attackers stop being theoretical. Anything signed and stored today with classical-only keys is on the clock.

OpenPGP is the long-tail use case. PGP-signed Linux package metadata, PGP-encrypted vendor security advisories, PGP-encrypted email with five-year retention obligations: those are the artifacts that survive long enough to matter post-Q-Day. Web TLS gets to roll over with browsers. PGP rolls over only when GnuPG ships, distros pick it up, and admins regenerate keys. That clock just started.

A 2025 survey of PQ support across crypto libraries ranked GnuPG behind OpenSSL and BoringSSL on PQ readiness. 2.5.19 narrows that gap.

Caveats and gotchas

• It’s a development release. Don’t put 2.5.19 on a production keyserver yet. The whole point of the 2.5 line is to shake out bugs before 2.6 stable.
• DoS on GnuPG infra. Koch’s announcement notes ongoing denial-of-service attacks against the project’s bug tracker, which has caused intermittent outages. Reporting issues against 2.5.19 may take longer to land than usual.
• No turnkey migration. There is no gpg --upgrade-to-pqc command. Generating a new PQ-hybrid key, distributing the public half to your correspondents, and getting them onto a current GnuPG is the workflow, and the tooling is bare-metal.
• Hybrid only. The OpenPGP PQ draft mandates hybrids (ML-KEM combined with X25519), not pure-PQ keys. That’s deliberate, and it’s the same posture TLS 1.3 took. Belt and suspenders until ML-KEM has a few more years of attack history.

What this means for you

If you maintain a release-signing key, an IT vendor advisory pipeline, or any long-retention encrypted archive, this is the release to read the notes on. You don’t need to migrate today. You do need to know that 2.6 stable, when it ships, will make PQ-hybrid encryption the path of least resistance. Software that depends on GnuPG (Debian’s repo signing, Linux kernel tarballs, pass, git signed commits when they use PGP, journalist-source secure mail) will need a plan for re-signing, key transition, and recipient compatibility.

For most of you, the right move this week is small: pull GnuPG 2.5.19 on a test machine, generate a PQ-hybrid key, encrypt a file to yourself, and confirm decryption works. The bigger question, the one you’ll want a real answer to before 2.6 hits, is which of your correspondents and which of your downstream tools (Thunderbird, Mailvelope, GitHub’s PGP verification) will refuse to talk to a PQ-hybrid key. The answer today is “most of them.” The window to fix that is the next 18 months, not the next five years.