gpg-2.3 rsa decryption has wrong size ciphertext
James.Bottomley at HansenPartnership.com
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
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...
Size: 228 bytes
Desc: This is a digitally signed message part
More information about the Gnupg-devel