For people wondering whether to migrate now: the practical question isn't "is a CRQC imminent" (it isn't), it's whether your encrypted messages have a useful lifetime longer than the optimistic deployment timeline.

If you encrypt a one-off email with a 5-year confidentiality requirement, harvest-now-decrypt-later actually matters. If you're encrypting backups that get rotated every 90 days, it doesn't.

The hybrid construction (Kyber/ML-KEM + X25519) is nice precisely because it's a no-regret move — you don't lose anything by adopting early. If Kyber turns out to have a structural flaw, X25519 still protects you. If a CRQC arrives, ML-KEM still protects you. The only real cost is key/ciphertext size, which for OpenPGP isn't a hot path anyway.

The interesting question is what happens to long-lived smartcard/HSM-backed keys. Those typically have a 5–10 year lifecycle and most hardware won't grow ML-KEM support without a hardware refresh. That's where I'd expect the first real compatibility headaches.

> introduction of Kyber (aka ML-KEM or FIPS-203) as PQC encryption algorithm

Funny to read 1-liner changelog versus the plethora of articles just few years ago along the line of "Quantum computer, it might just change our entire lives and make privacy impossible!".

The simple addition (of a not so simple algorithm) to the software (and few others, e.g. OpenSSL) and voila, me can move on with our daily lives. Cryptography and computational complexity are truly amazing.

Does it implement the hybrid version ML-KEM-768 + X25519 or ML-KEM-768 only ?

The X25519 key could remain in hardware keys for a while til manufactures catch up.

GnuPG Version 2.5.19

The 2.5 series are improvements for 64 bit Windows and the introduction of Kyber (aka ML-KEM or FIPS-203) as PQC encryption algorithm.

The old 2.4 series reaches end-of-life in just two months.

I don't know enough about either the technical nuance or the political drama, but some observers have noted that GnuPG's implementation is (deliberately?) incompatible with the IETF's standards. It's not clear why.

https://floss.social/@hko/116459621169318785

been thinking about this a bit. someone just tell me what algo to use and ill start using it now. are the quantum-resistant cryptos significantly slower?

cool, now my emails that nobody's reading anyway are safe from quantum computers that don't exist yet

[flagged]

[dead]

GPG seems… weird?

https://floss.social/@hko/116459621169318785

> While GnuPG 2.5.x implements hybrid PQC encryption based on ML-KEM, […] GnuPG's implementation is entirely incompatible with the IETF-specified format, which all other libraries are implementing.

> Both serialization and the KEM combiners differ.

> The bottom line is that anyone who wants to use vendor-agnostic PQC with OpenPGP should avoid GnuPG's PQC key formats.

> This is all exceedingly unfortunate and weird, and frankly, a total disgrace.

> Also see https://chaos.social/@dvzrv/116460347482223544

> It would appear that GnuPG upstream is trying to use its influence to create facts on the ground (by proliferation of its proprietary non-OpenPGP formats).

https://floss.social/@hko/116464388341452694

> GnuPG's new, non-OpenPGP formats are "proprietary in the governance sense":

> One actor unilaterally decides what they want to do, while not meaningfully engaging with anyone else.

> Then they implement their preference, and write up some document that more or less describes the format.

https://mastodon.ie/@andrewg/116464341607363847

> GnuPG is not proprietary, of course. But the “librepgp” formats that it promotes as an alternative to OpenPGP are “proprietary” in the sense that they are the work of a single person, who happens to be the GnuPG project lead, and have been rushed into production against the advice of nearly every other openpgp implementer.

https://floss.social/@dvzrv@chaos.social/116460347519274876

> I'm getting quite annoyed with the state of #GnuPG as a packager.

> Upstream silently keeps releasing 2.2 versions to this day(!) and at the same time claims 2.4 will soon be EOL (also refuses to backport security fixes for it).

> Meanwhile, there are no good reasons to upgrade to 2.5, unless one wants incompatibility with the entire rest of the ecosystem (see https://wiki.archlinux.org/index.php?title=GnuPG&oldid=86021...).

> The move to #OpenPGP #RFC9580 compliant solutions can't happen early enough!

> Also, I'm glad we have @freepg

> Everything gets even more wild once you notice that upstream itself appears to flag the package out of date and is trying to upsell the new features.

> Apart from the incompatibility madness: Without the #FreePG patches, there no longer would be #systemd support (which we require!) in 2.5, because upstream removed it (what seems to me, out of spite).

https://mastodon.ie/@andrewg/116464399797066586

> many of us suspect that the root of the problem is the age of gnupg’s codebase, which bakes in a lot of assumptions and premature optimisations, and which doesn’t have any unit tests or continuous integration. It’s a codebase that few outsiders understand and which few insiders are confident about making major changes to.

I feel a bit uneasy about entrusting my security to that mess.

https://floss.social/@hko/116465281149794524

> The good thing is that no one is forced to deal with GnuPG's increasingly odd choices.

> My perspective is that there is really only one sensible path forward: The formats that are developed by the OpenPGP WG at the IETF.

> There are half a dozen independent implementations of both RFC 9580 and draft-ietf-openpgp-pqc.

> It's clear that there is a lot of consensus, and will to modernize in a collaborative fashion.

> This is of course complicated by GnuPG effectively attempting to derail these developments

> I don't think there is anything constructive left to do, in that regard. Many people have tried to build many bridges. To no avail.

> The only remaining option is to try and protect captive GnuPG user bases from the fallout, as much as possible. This is the goal of @freepg

> The GnuPG situation is not great. But I think the ecosystem is being as constructive as circumstances allow.