Fingerprint mismatch for 384-bit ECDH keys generated on SmartCards
trevor at yubico.com
Tue Mar 12 14:50:08 CET 2019
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
Since secp384 is one of the only two curves offered when generating a
key without the `--expert` flag, this could be quite problematic for
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?
More information about the Gnupg-devel