I have seen a few other threads started on this problem I have just
encountered, or similar subjects, most notably one some months ago by
Edmond [at] systemli. However, I never saw a resolution posted, and I
believe I have more data to work with.
I have been using the ZeitControl OpenPGP cards for a few years now.
I have my primary keys on a v2.0 card, and they have been working fine
(for the most part). These are 3072 bit keys.
I recently learned of the support for 4096 bit keys on cards, added
with GnuPG 2.0.18, and since I had an extra, blank card laying around,
I decided to experiment with it. I started by updating to the latest
version of GnuPG (2.0.19 as of this writing) which I downloaded in
source form from ftp.gnupg.org. The source compiled without any
problems, and I verified that the installed binaries worked with my
existing keys and cards. This is on Mac OS 10.7.4.
On my spare OpenPGP card, I generated a 4096 bit cert/signing key, a
4096 bit encryption key, and a 2048 bit authorization key. All of the
keys were generated on the card itself. No errors were reported
during the key generation process.
The 4096 bit signing key works perfectly. I have signed with it many
times, and the signatures verify properly. Likewise, the auth key
works for SSH logon, though it is a 2048 bit key.
However, whenever I try to decrypt a document encrypted to the
4096 bit encryption key on the card, the decryption process fails to
even begin, with an error like the following:
Version: GnuPG v2.0.19 (Darwin)
gpg: armor header:
gpg: public key is 0xA9D4A64F1FADF7D2
gpg: using subkey 0xA9D4A64F1FADF7D2 instead of primary key
0x24620B795999A6DB
gpg: using subkey 0xA9D4A64F1FADF7D2 instead of primary key
0x24620B795999A6DB
gpg: encrypted with 4096 bit RSA key, ID 0xA9D4A64F1FADF7D2, created
2012-05-16
"Kevin Kammer <kevin [at] hansaeditions.net>"
gpg: public key decryption failed: General error
gpg: decryption failed: No secret key
This is essentially the same error that Edmond described. I realize
it looks as though the private key (or rather, its stub, as it was
generated on the card and never left) is not on my keychain, but I can
assure you that is not the case. gpg -K shows the private key, and
examining it in reasonable detail with gpg --edit-key shows no
discrepancies either.
Since the 4096 bit size of the key is a new variable, I decided to
destroy the keys, and try to generate and test new keys of varying
strength on the card. To summarize, here are my findings:
SC E A Result
-------------------------------------------------------------
2048 2048 2048 All of them work
3072 3072 2048 All of them work
4096 3072 2048 All of them work
4096 4096 2048 SC works to sign, E fails to decrypt.
It is also worth noting that my results are the same using two
different card readers: SCM and Gemalto. I have not had the
opportunity to test with an entirely different computer/OS.
It's not really important to me to use 4096 bit keys vs. 3072; but if
I understood the release notes for v2.0.18+ this should work, correct?
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
