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

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.

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.

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.

> 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!".

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.

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

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.

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.

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.

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.

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

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

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?

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.

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.

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!]

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.

> 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 traditonal 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?

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.

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

Well:

> Category: Standards Track

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

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

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

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.

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)

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.

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

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

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

So low not so slow

> it won't 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?

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

Well:

> Category: Standards Track

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

It is very hard to prevent a proposal from becoming a RFC. You have to generate ongoing opposition for longer than the supporters. FWIW, here is the LibrePGP proposal:

* 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

It is a standard proposal, which is why it's in the standards track. The point was that it is not the only (the) standard, and not the universally accepted one.

(source: i talked to a GnuPG developer)

So low not so slow

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

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

It is very hard to prevent a proposal from becoming a RFC. You have to generate ongoing opposition for longer than the supporters. FWIW, here is the LibrePGP proposal:

* https://datatracker.ietf.org/doc/draft-koch-librepgp/

[1] https://www.cs.auckland.ac.nz/~pgut001/pubs/bollocks.pdf

It is a standard proposal, which is why it's in the standards track. The point was that it is not the only (the) standard, and not the universally accepted one.

Werner Koch wk at gnupg.org
Fri Apr 24 13:52:45 CEST 2026

Previous message (by thread): [Announce] [Security fixes] Libgcrypt 1.12.2, 1.11.3, 1.10.x released
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Hello!

We are pleased to announce the availability of a new GnuPG release: Version 2.5.19. This release adds a few new features and fixes a couple of bugs.

The main features in 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. Other than PQC support the 2.6 series will not differ a lot from 2.4 because the majority of changes are internal to make use of newer features from the supporting libraries.

Note that the old 2.4 series reaches end-of-life in just two months. Thus update to 2.5.19 in time. As always with GnuPG new versions are fully compatible with previous versions.

What is GnuPG

The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation of the OpenPGP and S/MIME standards.

GnuPG allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. The separate library GPGME provides a uniform API to use the GnuPG engine by software written in common programming languages. A wealth of frontend applications and libraries making use of GnuPG are available. As an universal crypto engine GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP.

GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License.

Noteworthy changes in version 2.5.19 (2026-04-24)

     \[compared to version 2.5.18\]

* New and extended features:

gpg: New option --use-ocb-sym. [rGccdcdfbb37]
gpg: New options --show-[only-]session-hash. [rGecd0f7afa1]
gpgsm: Allow cipher mode to be part of the algo given to the --cipher-algo option. [T3979]
gpgsm: Emit more details when failing to check a crlDP. [T8221]
agent: Improve pinentry behavior and texts in smartcard context. [T6425]
dirmngr: New keyword "clear" for --keyserver. [rG2ab4cba36c]

* Bug fixes:

gpg: Fix edge case in --refresh-keys. [T8197]
gpg: Don't call gcry_kdf_derive with empty passphrase. [T7739]
gpgsm: Skip the optional PKCS#12 PBES2 keyLength parameter to allow import of recently issued certificates by the German Telekom. [rGc8c9604bba]
gpgsm: Fix a bug so that a certificate can be signed using a different algo. [rG66fdafab3c]
gpgsm: Make GCM fully compliant in de-vs mode. [rG04fd775fce]
gpgsm: Add a certificate chain check for de-vs compliance. [T8188]
gpgsm: Show rsaPSS certificates as de-vs compliant in listings. [T8222]
agent: Rework the trustlist reading code to finally allow a trustlist.txt with a missing trailing LF. [T8078]
ssh: Fix RSA padding in signature handling. [T7882,T8202]
gpgtar: Fix -C (--directory) to check the output directory. [T8159]

* Other changes:

agent: Raise an error when p >= q for RSA keys to detect incorrect generated *PGP keys. [T8171]

Release-info: https://dev.gnupg.org/T7998

Getting the Software

Please follow the instructions found at <https://gnupg.org/download/> or read on:

GnuPG may be downloaded from one of the GnuPG mirror sites or direct from its primary file server. The list of mirrors can be found at <https://gnupg.org/download/mirrors.html>. Note that GnuPG is not available at ftp.gnu.org.

The GnuPG source code compressed using BZIP2 and its OpenPGP signature are available here:

https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.19.tar.bz2 (8127k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.19.tar.bz2.sig

An installer for Windows without any graphical frontend except for a very minimal Pinentry tool is available here:

https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.19_20260424.exe (5627k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.19_20260424.exe.sig

The source used to build this installer for 64-bit Windows is available as

https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.19_20260424.tar.xz (15M) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.19_20260424.tar.xz.sig

This source tarball may also be used to download all required libraries at once to build a Unix version on any modern system. See the included README.

Debian Packages

We also provide Debian style packages for a couple of Debian variants. See https://repos.gnupg.org/deb/gnupg/trixie/ or use the menu to switch to other distros/releases. If you encounter packaging problems please report them to the gnupg-devel mailing list. Due to the holidays it may take a few days until the packages are available.

Windows Installer

A new Version of Gpg4win is in planning. For those who are affected by one of the now fixed bugs, it is possible to install the simple Windows installer mentioned above on top of gpg4win 5.0.1.

Checking the Integrity

In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways:

* 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:

 sha1sum gnupg-2.5.19.tar.bz2

and check that the output matches the next line:

dbe9ce2aca9d553ed4367692575cee15204a95a6 gnupg-2.5.19.tar.bz2 e4de189d1310893b2f8e565781d25093944b883e gnupg-w32-2.5.19_20260424.tar.xz a2b9b2d0ad979209e1c74f28ff910ce6f97f0e41 gnupg-w32-2.5.19_20260424.exe

Internationalization

This version of GnuPG has support for 26 languages with Chinese, Czech, Dutch, French, Georgian, German, Italian, Japanese, Norwegian, Polish, Portuguese, Russian, Turkish, and Ukrainian being almost completely translated.

Documentation and Support

The file gnupg.info has the complete reference manual of the system. Separate man pages are included as well but they miss some of the details available only in the manual. The manual is also available online at

https://gnupg.org/documentation/manuals/gnupg/

or can be downloaded as PDF at

https://gnupg.org/documentation/manuals/gnupg.pdf

You may also want to search the GnuPG mailing list archives or ask on the gnupg-users mailing list for advise on how to solve problems. Most of the new features are around for several years and thus enough public experience is available. https://wiki.gnupg.org has user contributed information around GnuPG and relate software.

If you are using cleartext signatures in your application please read https://gnupg.org/blog/20251226-cleartext-signatures.html and maybe https://gnupg.com/20260122-39C3_reply_gpg_fail.html

In case of build problems specific to this release please first check https://dev.gnupg.org/T7998 for updated information. We are sorry that due to ongoing DoS on this service, you may end up at a "is under maintenance page".

Please consult the archive of the gnupg-users mailing list before reporting a bug: https://gnupg.org/documentation/mailing-lists.html. We suggest to send bug reports for a new release to this list in favor of filing a bug at https://bugs.gnupg.org. If you need commercial support go to https://gnupg.com or https://gnupg.org/service.html.

If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion.

Thanks

Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH and has mostly been financed by donations. A team of full-time employed developers and contractors are working exclusively on GnuPG and related software like Libgcrypt, GPGME, Kleopatra, Okular, and Gpg4win.

Fortunately, and this is still not common with free software, we have established a way of financing the development while keeping all our software free and freely available for everyone. Our model is similar to the way RedHat manages RHEL and Fedora: Except for the actual binary of the MSI installer for Windows and client specific configuration files, all the software is available under the GNU GPL and other Open Source licenses. Thus customers may even build and distribute their own version of the software as long as they do not use our trademarks GnuPG Desktop® or GnuPG VS-Desktop®.

We like to thank all the nice people who are helping the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, answering questions on the mailing lists, or helped with donations.

*Thank you all*

Your GnuPG hackers

p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users at gnupg.org mailing list.

* Debian Package Signing Key: The new Debian style packages are signed using this key:

ed25519 2025-07-08 [SC] [expires: 2035-07-14] 3209 7B71 9B37 45D6 E61D DA1B 85C4 5AE3 E1A2 B355 GnuPG.org Package Signing Key <package-maintainers at gnupg.org>

See the package website (https://repos.gnupg.org/deb/gnupg) for a list of supported distributions and a download link for the key.

* List of Release Signing Keys: To guarantee that a downloaded version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these five keys:

ed25519 2020-08-24 \[SC\] \[expires: 2030-06-30\]
6DAA 6E64 A76D 2840 571B  4902 5288 97B8 2640 3ADA
Werner Koch (dist signing 2020)

ed25519 2021-05-19 \[SC\] \[expires: 2027-04-04\]
AC8E 115B F73E 2D8D 47FA  9908 E98E 9B2D 19C6 C8BD
Niibe Yutaka (GnuPG Release Key)

rsa3072 2025-05-09 \[SC\] \[expires: 2033-03-03\]
3B76 1AE4 E63B F351 9CE7  D63B ECB6 64CB E133 2EEF
Alexander Kulbartsch (GnuPG Release Key)

brainpoolP256r1 2021-10-15 \[SC\] \[expires: 2029-12-31\]
02F3 8DFF 731F F97C B039  A1DA 549E 695E 905B A208
GnuPG.com (Release Signing Key 2021)

brainpoolP384r1 2026-02-23 \[SC\] \[expires: 2034-02-23\]
1493 269D E61F 124A A69A  316E 3ADF 34EB DBB2 00A4
GnuPG.com (Release Signing Key 2026)

The keys are available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key.