When creating keys on a OpenPGP card (v2) with gnupg 2.1.9 the key fingerprints
on the card difer from the ones that appear in the local keyring (see attached
log). This obviously makes the cards unusable as gpg doesn't find the keys it's
looking for (for signing, etc)
This worked ~half a year ago (Arch Linux, so always fairly new versions).
I tried with multiple cards (248 in fact) but only on one computer.
Please run
gpg --with-keygrip --with-fingerprint --with-fingerprint -K 30A99F9A
and
gpg --with-keygrip --with-fingerprint --with-fingerprint -K 9BA84708
If one of the commands does not show a key run it again with -k
(lowercase). Also run
gpg --version
Thank you for the bug report. The ratio of 1 failure among 248 made me a great
hint to locate the bug.
I think that it is fingerprint computation bug, which is fixed here:
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=d40975cbe8ff86fcc4a1b4963fdffc66ddee85ce
gniibe: its not one failure in 248. It was 248 failures in 248 tries...
werner: I had to downgrade to have a working system. I hope I'll find time to
reproduce this this week
Sorry for my mistake for reading your post. I considered it would be the case
for m, but I also fixed the case for e, the exponent.
Here, I reproduce the problem with OpenPGPcard (while it only occurs 1/256 with
Gnuk Token).
I confirmed that original OpenPGPcard returns e as four bytes 00 01 00 01 with
0x00 in front. This causes 100% failure for fingerprint computation.
I'm going to test the patch with OpenPGPcard. (I'm now installing newer
libgpg-error, to build master of GnuPG.)
For my case with OpenPGPcard, the patch fixed the problem of wrong fingerprint
computation. Please test with the patch.