[PATCH 0/2] Changes to rsa_decrypt behavior on bad keys

[NIIBE Yutaka]

Hello,

Sorry for late reply.  I misunderstood/confused as your message were
sent to gnupg-devel.

FYI, I replied to gnupg-devel about the issue of P >= Q:

    https://lists.gnupg.org/pipermail/gnupg-devel/2026-July/036329.html

Our ticket is:

    https://dev.gnupg.org/T8171

Repeat: Such a key should not be used by GnuPG.

David Galos wrote:
> There are two following patches, and I think at least one of them is
> pretty important because the failure rate of a gcrypt-based crypto
> oracle could probably leak info about factor-proximity based on failure
> rate.

Thank you for your work.  It is important.  I agree.

My concern is: If a key (P >= Q) has been used and (many) signatures are
already available out there, such a key would not be safe.  Case by case
judgement and manual handling would be needed for such a key.

I don't think [PATCH 2/2] is good fix for a library, when a library
assumes/claims "p is smaller than q" in other parts.  It would introduce
another confusion.  For libgcrypt, mpi_subm is computationally heavy
than mpi_sub+mpi_add, we don't modify like that.

For [PATCH 1/2], for libgcrypt, I think that it is better for an
application to use standard function of gcry_pk_testkey to check a key
(or validate values before creating SEXP of libgcrypt).  It should not
be within a specific operation.  I mean, it should be done **beforehand**.

In libgcrypt, for some reason, p < q has been not tested by
gcry_pk_testkey.  It is enabled with ENABLE_STRONGER_CHECK now.
--