Pushed: rG8b6de59ad880: agent: Raise GPG_ERR_BAD_SECKEY when p >= q for RSA key.

While I pushed the change of libgcrypt, I'd like to apply following change to GnuPG.
This is more kind than GPG_ERR_BAD_PASSPHRASE by gcry_pk_testkey failure.

I retract my patch in T8171#215603

@m.eik gave us this link: https://github.com/ProtonMail/go-crypto/issues/184

Setting to low because this has never been a problem in the last 30 or 35 years. A check to help pinpointing bad keys is however a good idea.

I sent a patch to gcrypt-devel mailing list for the preparation of the change of RSA secret key checking.
If enabled, wrong RSA secret key (wrong means: under the Libre/OpenPGP specification) is rejected at import when gpg-agent calls gcry_pk_test_key.

BTW, LibrePGP also demands p < q in "Algorithm-Specific Part for RSA Keys".

For OpenSSH, ssh-agent spec. defines p, q, and qInv.
FIPS has: FIPS 186-5 and SP 800-56Br2.

existing standards

CRT is used with GnuPG. In libgcrypt, pk_sign and pk_decrypt don't require P, Q, and U in a key (it's optional), but pk_test_key does.

Du we have any information on whether the CRT is used and whether u et al. is also wrong? For example due to an OpenSSL generated key?

The reporter informed:
CVE-2025-69913

Fixed in 1.12.1.

Fixed in 1.12.0.

FWIW: Okay, gmime is still a wrapper around gpgme. After decryption it has the ability to get the used session key from the gpgme result structure. Thus, I have been on the wrong trail. The actual problem is not gpgme but more GnuPG's use of Libgcrypt or an actual regression in Libgcrypt. Well, Friday 13th.

Any hints where to find the actual crypto code which uses libgcrypt?

Maintainer of the FreeBSD notmuch port/package here. The steps below consistently trigger the problem on FreeBSD 16.0 (unreleased main branch), but there are no problems on FreeBSD 15.0. All my testing was on amd64.

Any hints where to find the actual crypto code which uses libgcrypt?

@thesamesam Thanks a lot.
I managed to replicate the failure somehow (for me, it fails at the importing the key).

I've attached notmuch-bug.log with debug-level guru commented out for gpg-agent:

I can reproduce it using Stuart's script from https://lists.gnupg.org/pipermail/gcrypt-devel/2026-February/006031.html.

Please tell us the information of your environment.
What the versions of gpg and gpg-agent?

We have seen the same thing on amd64 (x86_64) linux: https://bugs.gentoo.org/969501

No, OpenBSD's implementation of POSIX semaphore is different to NetBSD.
(It doesn't support PSHARED=1.)

Possibly, it is related to the NetBSD failure of T8065.
If importing the secret key fails (which invokes gpg-agent), decryption cannot be succeeded.
I will check OpenBSD implementation of POSIX semaphore, if it's similar to NetBSD one.

According to the ML @gniibe tried to replicate the problem without success.

Will go into 1.12.1

Thanks. Will go int the next version.

Thank you, that did indeed fix the problem!

Does following patch help?

Fixed in: rC2c1d41b5f86f: fips,cipher: Fix the regression with disabled public-key algo.

Re-opened because a regression is reported.

Backports have been done in both (1.10/1.11) branches.

Okay, let's backport this.

gpgrt 1.57 will come with gpgrt_fconcat. This can be used to get the sysconfig in a portable way:

@werner For rCd5e3cbfd , my mingw (GCC version 14) complains about the function-return-type difference of the prototype with GetProcAddress.

Scute fixed in rSc3dc9c581631: w32: Use CSIDL_COMMON_APPDATA if available.

Okay, forward porting that patch is the easiest solution. Actually this is not enough: Users of Libgcrypt also need to make sure that the new sysconfig dir has the right permissions. That's a part for the installer and concrete ACLs may differ.

I examined the code of gnupg_sysconfdir in gnupg/common/homedir.c, if we could factor out things to gpgrt, so that something like gpgrt_fconcat with GPGRT_SYSCONFDIR can be implemented.

I checked the code under gnupg/dirmngr. Those are no harm.

Applied to 1.11 branch.

I think this is correct even on Unix in case someone really uses /usr/local/etc (which I consider problematic). But for Windows we need to determine this at runtime.

For gpgrt/argparse this could be an option (to remove hard-coded /etc):

Note that:
If we consider backporting this to 1.10/1.11 branch, we also need to apply: rCdef1d4ea8f66: random:jent: Fix build with address sanitizer.

@jukivili
Thanks for your feedback.

There's GCRYPT_IN_ASAN_TEST environment variable check in tests/t-secmen.c and tests/t-sexp.c. Are those check needed after this change? Could they be removed?

For the initial attempt, I push: rCfe06287003a1: secmem: Handle HAVE_BROKEN_MLOCK for the case with ASAN.
This is better than nothing.

It's in master (to be 1.12), then, it's backported to 1.11.2, which is confirmed build well.
So, closing.

Thanks for testing.

Hello,
thank you all. I can confirm that 1.11.2 builds successfully on ppc64el with gcc-15 (Debian sid + experimental). Lacking access I have not be able to check alpha. I would suggest closing this report as fixed.
cu Andreas

1.11.2 has been release see T7642

Release done.

In T7642#203189, @gniibe wrote:

I wonder about GCC 15 preparation for the release. If it's good to have, three patches are needed to apply:

Ok, thanks. I pushed the powerpc patches to master.

I pushed the longlong patch: rCb61a7661d017: mpi: Provide the function prototype of __udiv_qrnnd.

IIUC, it's actually binutils version dependency (instead of GCC 15), perhaps.

I tested Ubuntu's version of GCC-15 (powerpc64le cross-compiler) and did not see this build failure:

In T7721#203182, @gniibe wrote:

For PowerISA 3.00 Instructions issue, following patch may help:

diff --git a/configure.ac b/configure.ac
index 6cc1e189..70d632af 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2448,10 +2448,11 @@ AC_CACHE_CHECK([whether GCC inline assembler supports PowerISA 3.00 instructions
         else
           gcry_cv_gcc_inline_asm_ppc_arch_3_00=no
           AC_LINK_IFELSE([AC_LANG_PROGRAM(
-          [[__asm__(".text\n\t"
+          [[__asm__(".machine        \"any\"\n"
+                    ".text\n\t"
                     ".globl testfn;\n"
                     "testfn:\n"
-                    "stxvb16x %r1,%v12,%v30;\n"
+                    "stxvb16x 47,0,9;\n"
                   );
             void testfn(void);
             ]], [ testfn(); ])],

I figured out that .machine "any" is needed with GCC 15.

I wonder about GCC 15 preparation for the release. If it's good to have, three patches are needed to apply:

• Cherry-picking rCd5fb7cd9b351: Mark nonstring use cases with __nonstring__ attribute.
  • strictly speaking, this adds a macro, which is considered an API change
• Cherry-picking rCf06e90f4137a: cipher:ecc: Silence GCC 15 warning.
• Apply changes of T7721: libgcrypt build-error with gcc-15 on powerpc and alpha

I figured out that .machine "any" is needed with GCC 15.