gpg-2.3 rsa decryption has wrong size ciphertext

[James Bottomley]

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
intentional.

> 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.

Thanks,

James

-------------- 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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20210308/09b4da52/attachment.sig>