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.
The X25519 key could remain in hardware keys for a while til manufactures catch up.
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.
Well:
> Category: Standards Track
* https://datatracker.ietf.org/doc/draft-koch-librepgp/
Observing the OpenPGP schism mess I think I have gained some insight as to why some RFCs become so bloated. For example it has been recently pointed out that there are 60 RFCs for TLS (with 31 drafts in progress)[1]. The RFC process seems to be more optimal during the design phase. Once we have an established standard there should to be some way to force those that propose changes/extensions to provide appropriately strong justifications for those changes/extensions. Right now it is a popularity contest and there will always be more people out there in favour of changes/extensions than those willing to endlessly fight against those changes/extensions. Because cryptography is so specialized and obscure, the users tend to get left out of the discussion.
[1] https://www.cs.auckland.ac.nz/~pgut001/pubs/bollocks.pdf
Combined with some personal drama.
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)
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.
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.
Here is a 6-part article about the topic: https://blog.cr.yp.to/20251004-weakened.html
* https://news.ycombinator.com/item?id=45477206
* https://news.ycombinator.com/item?id=45477206#unv_45477799
See various "NSA and IETF":
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!]
GnuPG did not unilaterally implement new non-OpenPGP formats. it kept supporting the old version of the OpenPGP standard. it unilaterally decided to NOT CHANGE its implementation. it's not trying to derail anything. the lack of engagement came from everyone else refusing to listen to the idea that you can't just break compatibility like that.
Arguing that you don't care about the right to privacy because you have nothing to hide is no different from saying you don't care about free speech because you have nothing to say. - Edward Snowden
https://gnupg.org/service.html https://gnupg.com/ https://g10code.com/
At least this comment didn't have the double quotes left in ˙ ͜ʟ˙
If you already have a version of GnuPG installed, you can simply
verify the supplied signature. For example to verify the signature
of the file gnupg-2.5.19.tar.bz2 you would use this command:
gpg --verify gnupg-2.5.19.tar.bz2.sig gnupg-2.5.19.tar.bz2
This checks whether the signature file matches the source file.
You should see a message indicating that the signature is good and
made by one or more of the release signing keys. Make sure that
this is a valid key, either by matching the shown fingerprint
against a trustworthy list of valid release signing keys or by
checking that the key has been signed by trustworthy other keys.
See the end of this mail for information on the signing keys.
* If you are not able to use an existing version of GnuPG, you have
to verify the SHA-1 checksum. On Unix systems the command to do
this is either "sha1sum" or "shasum". Assuming you downloaded the
file gnupg-2.5.19.tar.bz2, you run the command like this:
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.
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.