gpg-2.3 rsa decryption has wrong size ciphertext

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

gpg-2.3 rsa decryption has wrong size ciphertext

GnuPG - Dev mailing list
I finally got around to implementing unit tests for the TPM code and
I'm seeing periodic failures in the test that checks rsa
encryption/decryption.

What I'm seeing is that, occasionally (about once every 10 or so
times), for an rsa2048 key (the only size most TPMs do) a ciphertext of
length 257 is provided as input to pkdecrypt.  This causes an immediate
failure because the TPM is pre-programmed to accept only encrypted
messages of size 256 for rsa2048 keys.

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
256 bytes causes the decryption to succeed.

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.

James



_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: gpg-2.3 rsa decryption has wrong size ciphertext

GnuPG - Dev mailing list
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.

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.


Shalom-Salam,

   Werner


--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: gpg-2.3 rsa decryption has wrong size ciphertext

GnuPG - Dev mailing list
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


_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (235 bytes) Download Attachment