Card fails to decrypt using 4096-bit key

[Kevin Kammer]

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?