gpg-2.3 rsa decryption has wrong size ciphertext

James Bottomley James.Bottomley at
Tue Mar 9 02:53:40 CET 2021

On Mon, 2021-03-08 at 08:48 +0100, Werner Koch wrote:
> On Sun,  7 Mar 2021 16:43, James Bottomley said:
> > When I look at the contents of the wrong length messages, they have
> > a leading zero byte and simply stripping this off to reduce the
> > length to
> Yes, that is due to the way we hanlde bit integers (MPIs).  To make
> sure they are considered positive, we need to prefix them with a
> zero.

OK, that's the way ASN.1 handles it too, just checking it was

> Gniibe proposed a new data format for OpenPGP names SOS which is a
> simple octet string with a 2 byte big endian prefix given the _bit_
> count.  The reason for the bit count is that this aligns nicely with
> the MPIs as defined by OpenPGP with the exception that any leading
> _zero_ bits are also counted.
> This octet string may and partly is already used by GnuPG using
> Libgcrypt's Opaque MPIs.  We don't want to touch existsing code, thus
> standard Libgcrypt MPIs are still in use for RSA.
> > Is this expected behaviour from gcrypt?  I can simply code the TPM
> > routines to cope with the misbehaving length, but it looks like a
> > symptom of a truncation problem elsewhere in the code.
> Yes, you should strip exceeding zeroes.  We habe to do this in
> scdameon also.

OK, I added this to the tpm2 code.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <>

More information about the Gnupg-devel mailing list