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