Discussion:
OpenPGP - issue verifying userattribute signatures
KB Sriram
2014-06-21 06:08:17 UTC
Permalink
There is a bug in the way PGPUserAttributeSubpacketVector is
implemented, causing it to reject some valid signatures.

Attached are two different keys, with an identical image embedded and
signed as a userattribute in both keys. Also attached is code that
checks the signatures.

ok-attr.pkr passes the test, while pgp-attr.pkr fails the
test.

pgp-attr.pkr is a real key (in fact the PGP Global verification key)
and can be verified under gnupg, so the signature is valid.

The implementation bug is because pgp-attr.pkr chooses to express the
length of the embedded userattribute-subpacket as a 4-byte length even
though it can be expressed as a 2-byte length.

But by the time PGPSignature.verifyCertification() is called, the
packet has been converted into a UserAttributeSubpacket, and its
original length-encoding format is lost. When it is re-encoded, it is
written out and hashed with a 2-byte length, which then fails the
signature.

Is there a simple workaround? Unfortunately, it looks like the library
has to retain the original encoding in order to pass the signature.

-kb
David Hook
2014-06-22 23:45:47 UTC
Permalink
This issue, and the previous ones mentioned are fixed in the current
beta (18) of 1.51

http://downloads.bouncycastle.org/betas/

Regards,

David
Post by KB Sriram
There is a bug in the way PGPUserAttributeSubpacketVector is
implemented, causing it to reject some valid signatures.
Attached are two different keys, with an identical image embedded and
signed as a userattribute in both keys. Also attached is code that
checks the signatures.
ok-attr.pkr passes the test, while pgp-attr.pkr fails the
test.
pgp-attr.pkr is a real key (in fact the PGP Global verification key)
and can be verified under gnupg, so the signature is valid.
The implementation bug is because pgp-attr.pkr chooses to express the
length of the embedded userattribute-subpacket as a 4-byte length even
though it can be expressed as a 2-byte length.
But by the time PGPSignature.verifyCertification() is called, the
packet has been converted into a UserAttributeSubpacket, and its
original length-encoding format is lost. When it is re-encoded, it is
written out and hashed with a 2-byte length, which then fails the
signature.
Is there a simple workaround? Unfortunately, it looks like the library
has to retain the original encoding in order to pass the signature.
-kb
KB Sriram
2014-06-23 23:23:54 UTC
Permalink
Post by KB Sriram
There is a bug in the way PGPUserAttributeSubpacketVector is
implemented, causing it to reject some valid signatures.
[...]
This issue, and the previous ones mentioned are fixed in the current
beta (18) of 1.51
Awesome - thanks David, and for adding ECC support as well!

-kb

Loading...