Hi,
I discovered that GnuPG generates two mismatched fingerprints when
generating 384-bit ECDH keys on SmartCards. This applies to both
secp384 and brainpool384 decryption keys (stored in slot 1).
When the key is generated, two fingerprints are created via different
code paths. One is stored in the fingerprint slot on the smartcard, and
one is stored in the local keyring and in exported keys.
For ECDH keys, the last field hashed in the fingerprint is the "ECDH
params", of which the last byte is the KEK algorithm identifier. This
is hardcoded in scd/app-openpgp.c:ecdh_params() to 0x08, and hardcoded
in g10/ecdh.c:kek_params_table[] to 0x09. The mismatched byte obviously
results in a different SHA1 hash.
GnuPG itself appears to ignore the mismatch, and everything works as
expected. But OpenKeychain, the Android app, verifies that the
fingerprints match when importing a key for a smartcard. This obviously
fails, and only for 384-bit ECDH keys. It refuses to import the
decryption subkey, so the user is unable to decrypt messages with their
smartcard.
Since secp384 is one of the only two curves offered when generating a
key without the `--expert` flag, this could be quite problematic for
OpenKeychain users.
I would assume that the definition in ecdh.c should have been
CIPHER_ALGO_AES192... I did verify that changing it fixes the mismatch
and allows importing into OpenKeychain. But maybe changing it now
breaks all existing keys?
Thanks,
-Trevor
_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
I discovered that GnuPG generates two mismatched fingerprints when
generating 384-bit ECDH keys on SmartCards. This applies to both
secp384 and brainpool384 decryption keys (stored in slot 1).
When the key is generated, two fingerprints are created via different
code paths. One is stored in the fingerprint slot on the smartcard, and
one is stored in the local keyring and in exported keys.
For ECDH keys, the last field hashed in the fingerprint is the "ECDH
params", of which the last byte is the KEK algorithm identifier. This
is hardcoded in scd/app-openpgp.c:ecdh_params() to 0x08, and hardcoded
in g10/ecdh.c:kek_params_table[] to 0x09. The mismatched byte obviously
results in a different SHA1 hash.
GnuPG itself appears to ignore the mismatch, and everything works as
expected. But OpenKeychain, the Android app, verifies that the
fingerprints match when importing a key for a smartcard. This obviously
fails, and only for 384-bit ECDH keys. It refuses to import the
decryption subkey, so the user is unable to decrypt messages with their
smartcard.
Since secp384 is one of the only two curves offered when generating a
key without the `--expert` flag, this could be quite problematic for
OpenKeychain users.
I would assume that the definition in ecdh.c should have been
CIPHER_ALGO_AES192... I did verify that changing it fixes the mismatch
and allows importing into OpenKeychain. But maybe changing it now
breaks all existing keys?
Thanks,
-Trevor
_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
