Mailing List Archive: gpg-2.3 rsa decryption has wrong size ciphertext

gpg-2.3 rsa decryption has wrong size ciphertext

Mar 7, 2021, 4:43 PM

Post #1 of 3 (280 views)

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
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Re: gpg-2.3 rsa decryption has wrong size ciphertext [ In reply to ]

gnupg-devel at gnupg

Mar 7, 2021, 11:48 PM

Post #2 of 3 (280 views)

Permalink

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.

Re: gpg-2.3 rsa decryption has wrong size ciphertext [ In reply to ]

gnupg-devel at gnupg

Mar 8, 2021, 5:53 PM

Post #3 of 3 (280 views)

Permalink

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

Mailing List Archive

Attached Files:

Attached Files: