Re: Card fails to decrypt using 4096-bit key
On Wed, 31 Oct 2012 16:17, cor...@corsac.net said: Signing using a 4096R key works just fine, but decryption using an 4096R encryption key doesn't, with the same error. This is using GnuPG v2.0.19 on Debian sid, with pcscd 1.8.6 (in case that matters). I fixed this yesterday for 2.0 and master. The log file will now also show a note if you try to decrypt using a key 2048 with one of the non-working cards. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Card fails to decrypt using 4096-bit key
[sorry, I'm replying from an old mail and as I'm not subscribed I can't reply with the full text and correct headers] 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 Yes, I can confirm this. I have a recently bought OpenPGPv2 smartcard. Signing using a 4096R key works just fine, but decryption using an 4096R encryption key doesn't, with the same error. This is using GnuPG v2.0.19 on Debian sid, with pcscd 1.8.6 (in case that matters). I don't know if the issue is in GnuPG (wether gpg, gpg-agent or scdaemon) or in the smartcard, but I can do some debugging if needed. Please CC: me on replies, I'm not subscribed to the list. -- Yves-Alexis ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Card fails to decrypt using 4096-bit key
Hi, the problem seems to be on libassuan ASSUAN_LINELENGTH define (today is 1002). On g10/call-agent.c:998 (agent_scd_pksign) there is the following line: if (indatalen*2 + 50 DIM(line)) return gpg_error (GPG_ERR_GENERAL); and indatalen happens to be 512 for a 4096-bit key, which leads to a value greater then 1002 (1074 on this case). Applying the following patch solved the problem to me: diff -Nru libassuan-2.0.3.orig/src/assuan.h.in libassuan-2.0.3/src/assuan.h.in --- libassuan-2.0.3.orig/src/assuan.h.in2011-12-20 08:17:53.0 -0200 +++ libassuan-2.0.3/src/assuan.h.in 2012-06-26 22:58:47.483626831 -0300 @@ -67,7 +67,7 @@ #endif -#define ASSUAN_LINELENGTH 1002 /* 1000 + [CR,]LF */ +#define ASSUAN_LINELENGTH 1076 /* 1074 + [CR,]LF */ struct assuan_context_s; typedef struct assuan_context_s *assuan_context_t; @Werner: any comments on this change? Best Regards, -- Marcos A. Lenharo ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Card fails to decrypt using 4096-bit key
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 - 204820482048All of them work 307230722048All of them work 409630722048All of them work 409640962048SC 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
