GnuPG – post-quantum crypto landing in mainline

https://lists.gnupg.org/pipermail/gnupg-announce/2026q2/000504.html

by zdkaster • 3 months ago

174 57 3 months ago

lists.gnupg.org

zdkaster• 3 months ago

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.

utopiah2• 3 months ago

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.

BoppreH3• 3 months ago

It reminds me a lot of Y2K. The fix is simple, but finding the places where it's needed and doing it in a compatible way are absolutely non-trivial problems. The best we can hope is the same as Y2K: the plethora of articles convince businesses to invest large amounts of money to migrate algorithms, so that when a quantum computer arrives it won't be a big deal.

CatMustard• 3 months ago

it won't be a big deal.

This isn't a space I know too much about, but even if we all start using quantum-safe encryption for everything today, won't the arrival of quantum computers that can break traditional encryption not still be a big deal?

Given that intelligence agencies, tech companies and various bad actors have been storing encrypted data for a long time, hoping to decrypt when (if?) that day comes?

trueno4• 3 months ago

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?

d1sxeyes3• 3 months ago

Basically the idea is use hybrid. AES-GCM-256 or ChaCha20-Poly1305 for symmetric encryption (which is already PQ-safe), and ML-KEM looks set to become the standard for key encapsulation.

ML-KEM-768 is fast as an algorithm, faster than X25519 in terms of pure computation, but uses large keys, so has higher overheads on small payloads. Most of the time, they’re about equal, or the absolute time is so slow it doesn’t matter.

Most folks now are doing hybrid ML-KEM and X25519 to guard against undiscovered flaws in ML-KEM.

purplehat_2• 3 months ago

For people reading this, you may want to know the the NSA is allegedly trying to weaken hybrid ML-KEM and X25519 down to just ML-KEM. This is a good thing to pay attention to!

Here is a 6-part article about the topic: https://blog.cr.yp.to/20251004-weakened.html

cube2222• 3 months ago

It’s worth noting that e.g. the Go stdlib has this hybrid construction built-in via crypto/hpke.

d1sxeyes3• 3 months ago

So low not so slow

trueno4• 3 months ago

this is great, thanks. i'm a little lost on where I even need to apply this in my own work. for the most part I can think of like a small handful of places where i just symmetrically encrypt at rest, im guessing those should be updated. but for other things, i guess theres going to be a lot of waiting for a platform i dont control for instance to update it's support for things like private/public key authentication and more. i understand openssl supports a lot of these pq methods now, trying to gauge how much of a head start i can reasonably get.

ChaCha20-Poly1305

ha! i ran into this when looking at the source for yaak (guy who made the insomnia rest client who's now making yaak). i never got to the bottom of how it worked.

purplehat_2• 3 months ago

I believe ML-KEM is the standard algorithm for post-quantum asymmetric encryption. I think it's slower mainly because there's not good hardware support, but it shouldn't be a big deal because most encryption is hybrid where you only use the asymmetric crypto briefly to share a secret you can use for symmetric cryptography.

ML-KEM based on a lattice problem called "Learning With Errors", and there are similar lattice-based algorithms which have no known quantum speedup. Most traditional asymmetric encryption algorithms are based on number-theoretic assumptions like the discrete logarithm problem or the RSA assumption, which are broken by Shor's algorithm.

Symmetric cryptography (AES and SHA hash functions) are post-quantum resistant for now. Grover's algorithm technically cuts their asymptotic security in half, but that doesn't parallelize, so practically there is no known good quantum attack, and cryptographers and standards agencies tend to not worry about that. You can keep using those.

[edit: according to the sister comment posted simulataneously ML-KEM is faster than X25519. good to know!]

upofadown7• 3 months ago

For something like PGP, any performance difference wouldn't matter. There is one message and the key agreement is done once. As long as things are fast enough to be imperceptible to the user we are fine.

immanuwell• 3 months ago

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

PunchyHamster• 3 months ago

it's mostly to make clowns repeating "It's not PQ secure therefore bad" happy I think

aborsy• 3 months ago

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.

darkamaul• 3 months ago

If I understood the code correctly, it always use the hybrid version.

Kyber is always used in a composite scheme along with a classic ECC algorithm.

growse• 3 months ago

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

capitol_• 3 months ago

As far as I understood it: GnuPG started to implement stuff from the standard before it was finished, the standard continued to improve and GnuPG refused to change code already written.

Combined with some personal drama.

em-bee4• 3 months ago

it's not that simple. the new standard is a complete rewrite of the old one. they are not even compatible anymore. things the old standard used to support are not supported in the new standard. that makes any implementation of the new standard incompatible with implementations of the old one. GnuPG simply refused to stop supporting the old standard and decided to fork the standard itself. on the personal drama my interpretation is that it resulted from people backing the new standard being unhappy that GnuPG didn't go along.

my opinion is that rewriting standards like that is the result of design by committee. everyone wants to put their mark on it. designing a new standard is fine, but the new standard should have also received a new name, or it should at least have been acknowledged that the old standard still needs to be supported until enough time has passed that the old standard is no longer in use. (which could take decades if not more if we want to be realistic and consider that encrypted data at rest could linger around pretty much forever unless actively re-encoded.)

(source: i talked to a GnuPG developer)

upofadown7• 3 months ago

From the GnuPG prospective RFC-9580 is a deliberate fork away from what agreement could be achieved. Basically the faction that is now called RFC-9580 (mostly Sequoia and Proton) wanted to make a lot of changes to the existing standard but the faction that is now called LibrePGP (mostly GnuPG and RNP) was not convinced that those changes were necessary.

Traditionally the OpenPGP standards process has been very conservative and minimalistic. GnuPG comes from that tradition. So the RFC-9580 faction created their own maximalist version of the standard and are actively promoting it as the standard.

So from a user perspective, there are two incompatible proposals out there. It's a mess. So it is better to aggressively ignore them both and maintain interoperability by sticking with RFC-4880 (OpenPGP). That might be a problem if you for some reason are still concerned about a quantum attack against cryptography as the post quantum stuff has gotten caught in this schism. It is certainly something that the users need to keep in mind.

throw0101a3• 3 months ago

[…] and are actively promoting it as the standard.

Well:

Category: Standards Track

* https://datatracker.ietf.org/doc/html/rfc9580

woodruffw4• 3 months ago

It's not clear why.

The situation is farcical, and stems from the double bind that PGP has been in for at least 20 years: the standards are bad and need modernization, but it’s impossible to modernize them because the single thing that retains “serious” users of PGP is backwards compatibility.

The end result of this is a version of Weekend at Bernie’s where both GPG and OpenPGP are fighting over how to dress up the corpse, while the rest of the world has moved on.

Avamander• 3 months ago

The end result of this is a version of Weekend at Bernie’s where both GPG and OpenPGP are fighting over how to dress up the corpse, while the rest of the world has moved on.

Unfortunately there's something akin to a conflict of interest with both RNP and OpenPGP. OpenPGP guys have gpgsm, and RNP people also maintain the S/MIME part in Thunderbird. Both have stagnated and are holding back what would have otherwise moved on.

upofadown7• 3 months ago

PGP covers the case where data is encrypted and might stick around in that state for a long time. Decades. So backwards compatibility is essential.

Fortunately we can use the existing standard (RFC-4880) in a way that is completely secure. Remember, we are talking about the standard that was in effect when the Snowden leak revealed that PGP is on a very short list of things the NSA has no access to. There is no reason to think that has changed since then.

LtWorf• 3 months ago

Not every project has decided to let microsoft sign releases instead of checking developer's signatures.

Valodim2• 3 months ago

Short version: Werner Koch personally hates some people involved with the RFC9580 standardization, and cannot emotionally bear working with anything even loosely associated. He also struggled accepting anyone's opinion but his own while editor of the draft back then.

Search for "asking the editor to step down" to find the moment when the working group decided he was more trouble than it's worth (and GnuPG's support was obviously worth a lot in the openpgp community).

tokenhub_dev• 3 months ago

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.

BoppreH3• 3 months ago

Some Hardware Security Module manufacturers were smart enough to include FPGAs in their products, which they can now use to accelerate PQC algorithms without a hardware refresh.

The trouble is that PQC already has inherent size/performance downsides, and it won't benefit from the decades of optimizations that classical algorithms had. Expect a hefty performance tax for some time.

maqp2• 3 months ago

Could we finally get SHA256 fingerprints. Or BLAKE2, or SHA3-256, or SHAKE256, or BLAKE3, or LITERALLY ANYTHING BUT SHA-1, pretty please?

upofadown7• 3 months ago

Yes. Both standards proposals have SHA256 fingerprints.

Not that there is anything wrong with SHA1 fingerprints in practice. The sort of collisions that SHA1 is susceptible to are not an issue in this particular application. With SHA256 fingerprints people would still be using 64 bit key IDs, just like they are doing now.

Valodim2• 3 months ago

Rfc9580 is not a proposal anymore, it's a published RFC.

(I suppose strictly speaking it's still a "proposed standard" vs "internet standard", but so is basically everything else)

maqp2• 3 months ago

Thank goodness. Finally. Yeah I'm just not comfortable with 80-bit complexity against Grover, even if it's practically infeasible.

kstzv• 3 months ago

Does ML-KEM support all three NIST security levels (512/768/1024) in this integration? And is there any hardware acceleration planned or used for NTT, or is it purely software-based for now?

em-bee4• 3 months ago

in some of the comments here accusations have been made against GnuPG and their developers. one of the comments has been flagged and killed. i had the opportunity to talk to one developer for a few hours and learn a few things. there are still some open questions, but i want to do some research of my own before i talk to them again. let me share what i learned so far. since this response is addressing points made in various comments i decided to post it as a top level comment without quotes, just writing what i found out.

someone asked me to name the developer i talked to. i won't do that because in the past devs have been verbally attacked and threatened. justified or not, this is not acceptable behavior, and i am not going to expose anyone to that.

on the question of LibrePGP being the work of one person, i already mentioned that i found that the old OpenPGP RFC 4880 is 90% unchanged in LibrePGP. turns out it goes even further. almost all of the LibePGP RFC was already created by the OpenPGP committee. until some people pushed for massive changes. it was only at that point that werner koch decided to fork the standard and publish the old, already agreed upon, almost ready for publication, version of OpenPGP as LibrePGP with minimal changes. so this whole idea that LibrePGP is the work of one person is simply not true. this is documented in the timeline on https://librepgp.org/#timeline

the key issue with the new OpenPGP standard is not the changes in the supported crypto standards, but the incompatible key format, including the removal of the old keyformat. think about this for a moment please. clearly crypto algorithms need to be revised and improved over time, but there should be very little need to revise the key format, and especially remove support for the old format. i haven't verified this, but with the support for an old format gone, any old documents written in that format can no longer be decrypted by software following the new standard. the unreasonableness of this change is likely what set werner off, because he could not possibly remove support for the old format from GnuPG without breaking things for almost every user.

LibrePGP therefore is not an incompatible fork of OpenPGP, but OpenPGP RFC5980 is an incompatible revision of OpenPGP RFC4880 and of the latest consensus before people decided to massively change the OpenPGP RFC.

on the claim that GnuPG keeps silently releasing 2.2 versions, there is a simple explanation for that: GnuPG 2.2 is certified by the German Federal Office for Information Security (BSI). until a new version of GnuPG gets that certification, certain institutions that require this certification are not able to upgrade. think of 2.2 as an LTS release only intended for those that need it. there is nothing malicious about it, and insinuating that stopping support for 2.4 is in bad faith when 2.2 is still supported is simply missing the point. projects that have LTS releases do that all the time.

that mentioned refusal to backport something to 2.4 was not a refusal but an oversight. it has since been fixed.

the issue with the supposedly removed systemd support was a surprise to the person i talked to. but he could not confirm either way. we'll research that and follow up (feel free to email me if there is no reply here before the time to reply expires in two weeks. my email is in the profile). what my contact did tell me is that the systemd integration somehow made it more difficult to use GnuPG without that integration on machines running systemd. i didn't quite understand why though. if i learn more about this, i'll post it.

claims that the problem is the age of gnupg's codebase, which supposedly bakes in a lot of assumptions and premature optimisations, and which also supposedly doesn't have any unit tests or continuous integration, that it's a codebase that few outsiders understand and which few insiders are confident about making major changes to are very interesting but pretty baseless.

i mean how do you even make a claim that the codebase is full of assumptions and premature optimisations? what is the evidence for this claim? same for lack of tests. a claim like that would be very easy to verify. so please show your evidence, and don't make up stuff.

in my opinion this whole controversy is caused by people not listening to each other, and it is embellished by people who only follow one side of the argument and take everything that side claims as the truth. i am not exactly neutral myself, as i consider the GnuPG devs my friends, but i have a strong interest in resolving conflicts and misunderstandings and harmonizing different viewpoints. so i hope that my comments here are not adding fuel to the fire, but rather help to douse out the fire or at least cool it down.

it is also my hope that at some point in the future the differences between the new OpenPGP RFC and LibrePGP can be resolved, and the standards can be merged. (i don't know, it might be as simple as reinstating support for the old key format). forking a project in the face of controversy is not unknown in the FOSS community. it famously happened with GCC for example and a few other well known projects, which managed to overcome their differences and merge again. but to make this happen we need to stop throwing around accusations and actually listen to people to learn the reasons for their choices and opinions.

as long as we fight, we will just hinder each other in making progress. only if we collaborate and resolve our differences are we able to learn from our mistakes and move forward. this, btw, is the mantra that i live for, and this is why i chose to get involved in this discussion.

please share this comment with anyone who needs to see it.

GnuPG – post-quantum crypto landing in mainline

Related Stories