Fingerprint mismatch for 384-bit ECDH keys generated on SmartCards

[Trevor Bentley]

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