gcrymdblockwrite in cipher/hash-common.c in Libgcrypt version 1.9.0 has a heap-based buffer overflow when the digest final function sets a large count value. It is recommended to upgrade to 1.9.1 or later.
Libgcrypt before 1.8.1 does not properly consider Curve25519 side-channel attacks, which makes it easier for attackers to discover a secret key, related to cipher/ecc.c and mpi/ec.c.
cipher/elgamal.c in Libgcrypt through 1.8.2, when used to encrypt messages directly, improperly encodes plaintexts, which allows attackers to obtain sensitive information by reading ciphertext data (i.e., it does not have semantic security in face of a ciphertext-only attack). The Decisional Diffie-Hellman (DDH) assumption does not hold for Libgcrypt's ElGamal implementation.
GnuPG Libgcrypt could allow a remote attacker to obtain sensitive information, caused by improper handling of ElGamal encryption. By using side-channel attack techniques against mpipowm, and the window size, an attacker could exploit this vulnerability to obtain sensitive information, and use this information to launch further attacks against the affected system.
Last updated 25 August 2025
Last updated 27 May 2026
In Libgcrypt before 1.7.7, an attacker who learns the EdDSA session key (from side-channel observation during the signing process) can easily recover the long-term secret key. 1.7.7 makes a cipher/ecc-eddsa.c change to store this session key in secure memory, to ensure that constant-time point operations are used in the MPI library.
The ElGamal implementation in Libgcrypt before 1.9.4 allows plaintext recovery because, during interaction between two cryptographic libraries, a certain dangerous combination of the prime defined by the receiver's public key, the generator defined by the receiver's public key, and the sender's ephemeral exponents can lead to a cross-configuration attack against OpenPGP.
An implementation flaw was discovered in multiple cryptographic libraries that allows a side-channel based attacker to recover ECDSA or DSA private keys. When these cryptographic libraries use the private key to create a signature, such as for a TLS or SSH connection, they inadvertently leak information through memory caches. An unprivileged attacker running on the same machine can collect the information from a few thousand signatures and recover the value of the private key.
External References:
https://www.nccgroup.trust/us/our-research/technical-advisory-return-of-the-hidden-number-problem/
Last updated 27 May 2026
Libgcrypt before 1.12.2 sometimes allows a heap-based buffer overflow and denial of service via crafted ECDH ciphertext to gcrypkdecrypt.
The following announcement regarding libcrypt security releases was posted to gnupg-announce and related lists today. The forward is unedited except for trimming some footers inserted by mailing list software and the PGP/MIME signature.
----- Forwarded message from Werner Koch via Gnupg-devel <gnupg-devel () gnupg org> -----
Date: Tue, 21 Apr 2026 12:28:09 +0200 From: Werner Koch via Gnupg-devel <gnupg-devel () gnupg org> To: gnupg-announce () gnupg org Cc: Werner Koch <wk () gnupg org>, info-gnu () gnu org Subject: [Announce] [Security fixes] Libgcrypt 1.12.2, 1.11.3, 1.10.x released
Hello!
We are pleased to announce the availability of couple of new Libgcrypt versions: 1.12.2, 1.11.3, and 1.10.4 . It is suggested to use 1.12.2 which is fully compatible with all earlier versions.
This version fixes a security bug [T8211] which can be used used to mount a DoS using ECDH encryption (with NIST, Brainpool, X448, or X25519 curves). Note that GnuPG versions since 2.5.7 are not affected by this bug due to the use of a different encryption API.
Another security bug [T8208] was fixed in the Dilithium signing algorithm which is available since version 1.12.0.
Noteworthy changes in version 1.12.2 (2026-04-15) ====================================
Bug fixes:
- Fix possible ECDH buffer overwrite with zeroes. [T8211]
- Add a missing bounds check to the Dilithium context handling. Reported by Calif.io in collaboration with Claude and Anthropic Research. [T8208]
- Add point validation when using the new KEM interface. [T8212]
Other:
- Fix the dead-code of strongerkeycheck for RSA. [T8171]
For a list of links to commits and bug numbers see the release info at https://dev.gnupg.org/T8114 . However, due to an ongoing AI scraper DDoS the site might not be reachable at all times or from all IPs.
Noteworthy changes in version 1.11.3 (2026-04-21) ====================================
Bug fixes:
- Fix possible ECDH buffer overwrite with zeroes. [T8211]
- Add point validation when using the new KEM interface. [T8212]
- Fix compiler error on NetBSD. [T7633]
- mceliece6688128f: Fix stack overflow crash on win64/wine [rCb17ed8d1af]
- Apply a Kyber patch from upstream. [rC5ba143d51f]
- Use CSIDLCOMMONAPPDATA instead of /etc on Windows. [rC995b870fd2]
- Use secure MPI in gcrympiassignlimbspace. [rC520c699c82]
- Fix a regression with disabled public-key algo for FIPS. [T7338,rCc6e0658004]
Other:
- Handle HAVEBROKENMLOCK for the case of building with ASAN. [T7889]
- Add stack burning for PQC algorithms. [rC289c0a596f]
Release-info: https://dev.gnupg.org/T8232
Noteworthy changes in version 1.10.4 (2026-04-21) ====================================
NOTE: The 1.10 series reaches end-of-life in 6 weeks.
Bug fixes:
- Fix possible ECDH buffer overwrite with zeroes. [T8211]
- Fix AESWRAP padding length check. [T7130]
Other:
- Handle HAVEBROKENMLOCK for the case of building with ASAN. [T7889]
Release-info: https://dev.gnupg.org/T8233
Download ========
Source code is hosted at the GnuPG FTP server and its mirrors as listed at https://gnupg.org/download/mirrors.html. On the primary server the source tarball and its digital signature are:
https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.12.2.tar.bz2 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.12.2.tar.bz2.sig https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.11.3.tar.bz2 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.11.3.tar.bz2.sig https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.10.4.tar.bz2 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.10.4.tar.bz2.sig
or gzip compressed:
https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.12.2.tar.gz https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.12.2.tar.gz.sig https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.11.3.tar.gz https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.11.3.tar.gz.sig https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.10.4.tar.gz https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.10.4.tar.gz.sig
In order to check that the version of Libgcrypt you downloaded is an original and unmodified file please follow the instructions found at https://gnupg.org/download/integritycheck.html. In short, you may use one of the following methods:
- Check the supplied OpenPGP signature. For example to check the signature of the file libgcrypt-1.12.2.tar.bz2 you would use this command:
gpg --verify libgcrypt-1.12.2.tar.bz2.sig libgcrypt-1.12.2.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 libgcrypt-1.12.2.tar.bz2, you run the command like this:
sha1sum libgcrypt-1.12.2.tar.bz2
and check that the output matches the first line from the this list:
7b8ff21966a0b6e7a735466b9b9b55d9dac9fa87 libgcrypt-1.12.2.tar.bz2 a1b1d5561e7b743e7e4460a49015053da1901124 libgcrypt-1.12.2.tar.gz d252f6b0a62fcacb8f82bcb61440b25d698a0a05 libgcrypt-1.11.3.tar.bz2 a89b597965a76bfbe0ad11e3d6153c3709c0b07e libgcrypt-1.11.3.tar.gz d824efa873ac210e84573564df4a99f4cd5cdf77 libgcrypt-1.10.4.tar.bz2 5a5bb8d4dd69a2c7828dbf31b12df5e21e604971 libgcrypt-1.10.4.tar.gz
You should also verify that the checksums above are authentic by matching them with copies of this announcement. Those copies can be found at other mailing lists, web sites, and search engines.
Copying =======
Libgcrypt is distributed under the terms of the GNU Lesser General Public License (LGPLv2.1+). The helper programs as well as the documentation are distributed under the terms of the GNU General Public License (GPLv2+). The file LICENSES has notices about contributions that require that these additional notices are distributed.
Support =======
For help on developing with Libgcrypt you should read the included manual and if needed ask on the gcrypt-devel mailing list.
In case of problems specific to this release please first check https://dev.gnupg.org/T8114 for updated information.
Please also consult the archive of the gcrypt-devel 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 .
Please see https://gnupg.org/documentation/security.html for information on how to report security issues and for our threat model.
If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gcrypt-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. Several full-time employed developers and contractors are working exclusively on GnuPG and closely related software like Libgcrypt, GPGME, Kleopatra and Gpg4win.
Fortunately, and this is still not common with free software, we have now 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 helping with donations.
Thank you all
Your Libgcrypt hackers
p.s. This is an announcement only mailing list. Please send replies only to the gcrypt-devel'at'gnupg.org mailing list.
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/signaturekey.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.
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 () 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.
-- The pioneers of a warless world are the youth that refuse military service. - A. Einstein
----- End forwarded message -----
I can't reach GnuPG's bug tracker at the moment so I can't check the mentioned bugs (if they're even public, I don't know) to see if they have the security impact I assume they might based on the description below.
One thing I did see, however, is this from Lukasz Olejnik on X [0]:
Quoting the X post [0] I mention in the first comment: """ I reported this security bug to libgcrypt. The bug allowed an attacker to supply a degenerate/small-order Ed25519 public key that passes the initial curve check but triggers a fatal logbug during signature verification, aborting the entire process. This enables a reliable denial-of-service against applications verifying attacker-controlled keys/signatures, without requiring a valid signature.
I attach a reproducer: #include <gcrypt.h>
static int triggerAbort(void) { static const unsigned char identity[32] = {0x01}; static const unsigned char zero[32] = {0}; static const unsigned char encodedKey[33] = {0x40, 0x01}; gcrysexpt publicKey; gcrysexpt message; gcrysexpt signature;
gcrycheckversion(NULL); gcrysexpbuild( &publicKey, NULL, "(public-key(ecc(curve Ed25519)(flags eddsa)(q %b)))", (int)sizeof(encodedKey), encodedKey); gcrysexpbuild( &message, NULL, "(data(flags eddsa)(hash-algo sha512)(value %b))", 0, identity); gcrysexpbuild( &signature, NULL, "(sig-val(eddsa(r %b)(s %b)))", 32, identity, 32, zero);
return gcrypkverify(signature, message, publicKey); }
int main(void) { return triggerAbort(); } """
This release fixes that testcase.
Finally, there are some post-release commits which may also be security-relevant:
commit 3ed69d3fb85bac0901dc5b4899d7983cf1f7bbe7 Author: NIIBE Yutaka <gniibe () fsij org> AuthorDate: Fri Aug 28 15:25:22 2026 +0900 Commit: NIIBE Yutaka <gniibe () fsij org> CommitDate: Fri Aug 28 15:25:22 2026 +0900
cipher:rsa:pss: Fix SALT-LENGTH handling.
cipher/pubkey-util.c (gcrypkutildatatompi): For PUBKEYOPSIGN, just like for PUBKEYOPVERIFY, reject larger SALT-LENGTH as the comment says. Fix releasing LIST on error.
--
Fixes-commit: 0bd8137e68c201b6c2290710e348aaf57efa2b2e GnuPG-bug-id: 8377 Reported-by: JEAN Jeremy <Jeremy.Jean () ssi gouv fr> Signed-off-by: NIIBE Yutaka <gniibe () fsij org>
commit 612eb8c157c057feeaf17d30644fd65b05c5ea25 Author: NIIBE Yutaka <gniibe () fsij org> AuthorDate: Thu Aug 27 14:36:35 2026 +0900 Commit: NIIBE Yutaka <gniibe () fsij org> CommitDate: Thu Aug 27 14:40:17 2026 +0900
cipher:rsa:pss: Validate the length of hashed input.
cipher/rsa-common.c (gcryrsapssverify): Reject invalid input.
--
GnuPG-bug-id: 8391 Reported-by: JEAN Jeremy <Jeremy.Jean () ssi gouv fr> Signed-off-by: NIIBE Yutaka <gniibe () fsij org>
commit cf55ce42d0268f9cfd7abc43aa4ec62d2e8c3f53 Author: NIIBE Yutaka <gniibe () fsij org> AuthorDate: Thu Aug 27 13:47:19 2026 +0900 Commit: NIIBE Yutaka <gniibe () fsij org> CommitDate: Thu Aug 27 13:47:19 2026 +0900
cipher:rsa:oaep: Validate all-zero PS.
cipher/rsa-common.c (gcryrsaoaepdecode): Reject non-zero PS.
--
GnuPG-bug-id: 8390 Reported-by: JEAN Jeremy <Jeremy.Jean () ssi gouv fr> Signed-off-by: NIIBE Yutaka <gniibe () fsij org>
[0] https://x.com/lukOlejnik/status/2093348278511219044
-------------------- Start of forwarded message -------------------- To: gnupg-announce () gnupg org Date: Thu, 27 Aug 2026 10:26:55 +0200 Subject: [Announce] Libgcrypt 1.12.3 released From: Werner Koch via Gnupg-announce <gnupg-announce () gnupg org> Cc: Werner Koch <wk () gnupg org>, info-gnu () gnu org Hello!
We are pleased to announce the availability Libgcrypt version 1.12.3. This version fixes a couple of minor bugs, introduces an additional name for an existing curve, and provides some performance improvements.
Noteworthy changes in version 1.12.3 (2026-08-26) [C28/A8/R0] =================================================
Bug fixes:
- Avoid theoretical drive-by loading of netapi32.dll and shell32.dll. [T8375]
- Validate hash algorithm for use with RSA modulus. [T8376]
- Validate parameters of Balloon KDF. [T8374,T8383]
- Validate parallelism of Argon2 KDF. [T8373,T8382]
- Fix parsing quoted parts and CRLF/LFCR in s-expression. [T8371]
- Support BUFLEN check for GCRYMPIFMTSSH. [T8371]
- Fix RSA PSS verify message length checking. [rC0d64fc228f]
- Avoid a NULL ptr deref due to a unsupported genkey flag for ECC. [rC3b259530bc]
- Assert 32 KiB input cap in gcmctrencrypt. [T8387]
- Fix assertion failure in OCB when a buffered block becomes block 65536. [T8389]
- Fix OOB read in IMIT MAC verify of GOST28147. [T8388]
- Fix CMAC block-count truncation for 64 GiB writes. [T8384]
- Fix AEAD spurious byte-counter carry for 4 GiB adds. [T8381]
- Validate all KEM input lengths. [T8259]
- Add length check of DATALEN when parsing s-expression. [T8267]
- Only accept canonical value for S with EdDSA. [T8386]
- Only accept canonical signatures for RSA. [T8392]
- Fix an assertion failure for invalid small-order Ed25519 public keys. [T8380]
- Validate length of supplied receiver public-key length in DHKEM decapsulation. [T8385]
- Use a more strict value for the PKCS#1 minimal frame length. [T8393,T8394]
Performance:
- Use just strong random for the Dilithium signature nonce and the Kyber encapsulation coins. [rC70ecc4e943,rCd7a3acc130]
- Allow internal users to skip fast random poll for ciphers and hashes. [rC75ff7a959b]
- Speedup sntrup761 by defer reduction in polynomial multiplication, reading random with a single call, and reducing freeze helpers w/o division. [rCbaa3a6376b,rC3f2f39bf75,rC317c661b16]
- Avoid byte-wise load/store on RISC-V with Zicclsm. [rCe18a5eb650]
- Use unaligned vector memory access on RSIV-V when supported. [rCecaa3572e1]
- Add Intel SM4 instructions accelerated AVX512 and AVX2 implementation. [rC14d1a882aa,rCdf44b486ba]
- Add Intel SM3 extension implementation. [rC3f94b92e05]
- Add Intel SHA512 extension implementation. [rC0f8a34038d]
Other:
- kyber: Accept and return a seed using the gcrypkgenkey API. [rCe099ccfea9]
- Add curve "ietf25" as alternative to "Curve25519" with exact RFC-8410 semantics. The name "X25519" was already used as an alias, thus this new name. [rC997217e600]
- Add straight-line speculation hardening for function ends. [rC9b684f4a44]
- Fix constant time memequal check for SM2. [T8395]
- Add post-quantum algorithm benchmarking to bench-slope.
- Due to the minor API updates and but with no newer branch released the SO name has been updated.
Release-info: https://dev.gnupg.org/T8223
Note that due to ongoing DoS our dev.gnupg.org server may not be reachable or has been blocked for some IP address ranges.
Download ========
Source code is hosted at the GnuPG FTP server and its mirrors as listed at https://gnupg.org/download/mirrors.html. On the primary server the source tarball and its digital signature are:
https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.12.3.tar.bz2 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.12.3.tar.bz2.sig
or gzip compressed:
https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.12.3.tar.gz https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.12.3.tar.gz.sig
In order to check that the version of Libgcrypt you downloaded is an original and unmodified file please follow the instructions found at https://gnupg.org/download/integritycheck.html. In short, you may use one of the following methods:
- Check the supplied OpenPGP signature. For example to check the signature of the file libgcrypt-1.12.3.tar.bz2 you would use this command:
gpg --verify libgcrypt-1.12.3.tar.bz2.sig libgcrypt-1.12.3.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 libgcrypt-1.12.3.tar.bz2, you run the command like this:
sha1sum libgcrypt-1.12.3.tar.bz2
and check that the output matches the first line from the this list:
b4654d75f0e5d0850cc699f02c9b44a06367502f libgcrypt-1.12.3.tar.bz2 e224bd8fe6709ef1471eefed35468fd1f4b9d3cc libgcrypt-1.12.3.tar.gz
You should also verify that the checksums above are authentic by matching them with copies of this announcement. Those copies can be found at other mailing lists, web sites, and search engines.
Copying =======
Libgcrypt is distributed under the terms of the GNU Lesser General Public License (LGPLv2.1+). The helper programs as well as the documentation are distributed under the terms of the GNU General Public License (GPLv2+). The file LICENSES has notices about contributions that require that these additional notices are distributed.
Support =======
For help on developing with Libgcrypt you should read the included manual and if needed ask on the gcrypt-devel mailing list.
In case of problems specific to this release please first check https://dev.gnupg.org/T8223 for updated information.
Please also consult the archive of the gcrypt-devel 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://dev.gnupg.org. If you need commercial support go to https://gnupg.com or https://gnupg.org/service.html .
Please see https://gnupg.org/documentation/security.html for information on how to report security issues and for our threat model.
If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gcrypt-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. Several full-time employed developers and contractors are working exclusively on GnuPG and closely related software like Libgcrypt, GPGME, Kleopatra and Gpg4win.
Fortunately, and this is still not common with free software, we have now 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 helping with donations.
Thank you all
Your Libgcrypt hackers
p.s. This is an announcement only mailing list. Please send replies only to the gcrypt-devel'at'gnupg.org mailing list.
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)
ed25519 2026-07-20 [SC] [expires: 2036-06-30] D02A E491 73BD AD56 E4F8 8223 707E 56D3 DEF4 115C Ingo Klöcker (Release Signing Key 2026) 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/signaturekey.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.
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 () 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.
-- 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 Gnupg-announce mailing list Gnupg-announce () gnupg org http://lists.gnupg.org/mailman/listinfo/gnupg-announce -------------------- End of forwarded message --------------------
Hi Sam!
On Mon, 31 Aug 2026 14:09, Sam James said: I can't reach GnuPG's bug tracker at the moment so I can't check the mentioned bugs (if they're even public, I don't know) to see if Fixed bugs are always public. In case we accidently missed to list the restriction, please let us know. We are really soprry about the problems but there is not much we can do. 400Hz SYN-Floods all from different IPs are not easy to handle. Our main goal is currently that we are able to work. We are also working on a solution for at least providing the static pages more reliable. One thing I did see, however, is this from Lukasz Olejnik on X [0]: Doesn't the use of what used to be Twitter not immediatley disqualify a report .-) I reported this security bug to libgcrypt. The bug allowed an attacker to supply a degenerate/small-order Ed25519 public key that passes the initial curve check but triggers a fatal logbug during signature Yes, this was fixed (T8380):
Small-order Ed25519 public keys reach a fatal internal arithmetic assertion Ed25519 verification checks that the supplied public point is on the curve but does not reject identity or other small-order points before scalar multiplication. A public gcrypkverify call with a degenerate attacker-supplied key can consequently reach logbug in the field arithmetic and abort the entire process before signature validity is decided. [...] cipher:rsa:pss: Fix SALT-LENGTH handling.
GnuPG-bug-id: 8377 Reported-by: JEAN Jeremy <Jeremy.Jean () ssi gouv fr> Unchecked PSS salt-length conversion reaches a near-SIZEMAX write
RSA-PSS signing parses the bounded salt-length atom without checking its length, parse endpoint, range, or errno, stores it as unsigned int, and passes it to an encoder taking int. On mainstream two's-complement ABIs, 4294967295 becomes -1; mixed signed/unsigned arithmetic then allocates a small buffer before gcryrandomize receives SIZEMAX, causing deterministic heap corruption through public gcrypksign. [...]
I commented on this:
In theory we could check for this but checking the salt length is a duty of the caller. Anyone who creates a s-expression large enough to reach a range limit has other problems in the code than this. cipher:rsa:pss: Validate the length of hashed input.
GnuPG-bug-id: 8391 RSA-PSS verification copies a full digest from an unchecked short opaque MPI
When RSA-PSS verification is told that the message is already hashed, it obtains an opaque MPI pointer but does not compare the MPI's bit length with the selected digest length. It unconditionally copies hlen bytes. A caller-supplied short opaque value therefore causes an out-of-bounds read before signature verification fails or continues with adjacent bytes. [...]
Callers should validate input data for plausibility. The reproducer would not pass a proper protocol parser. Fixed of course. cipher:rsa:oaep: Validate all-zero PS.
GnuPG-bug-id: 8390 RSA-OAEP decoder accepts nonzero bytes inside the zero padding string
After unmasking OAEP's data block, the decoder verifies lHash and searches for the first 0x01 delimiter. It does not verify that every byte between lHash and that delimiter is zero. A data block containing arbitrary nonzero padding bytes is therefore accepted and its suffix returned as plaintext.
Why it matters
OAEP requires DB to be lHash || PS || 0x01 || M with PS entirely zero. Accepting a larger language of encodings weakens strict ciphertext validation and can become useful if a protocol reveals success through output, errors, or timing. Constructing such an RSA ciphertext without the private key is not established here, so this finding is a decoder correctness flaw rather than a standalone decryption oracle.
All in all we received 26 reports alone from ANSSI but as even the reporter mentioned, the real world attack severity is not critical. Thus we don't consider 1.12.3 a security fix release. There are some bugs which should be fixed to avoid crashes, and thus may lead to DoS. However, 16384 bit RSA keys can also be used for a practical DoS; it all depends on your use case.
Salam-Shalom,
Werner
-- The pioneers of a warless world are the youth that refuse military service. - A. Einstein