There seems to be some kind of problem using gpg2 + CryptoStick to decrypt messages.
I’m experiencing this on all my computers (debian testing and unstable and Ubuntu 11.10):
signing using gpg2 works fine, 2) ssh + gpg-agent works fine, 3) gpg2 --card-status
reports the card like expected, 4) decryption with gpg2 fails, 5) decryption with gpg
works fine.
I’ve seen signs on mailing lists and web pages that this may be a general problem,
though I’m not sure as there should have been more reports of it by now if it was.
My temporary solution is of course to use gpg for decryption and gpg2 for
everything else, but that is suboptimal with mail readers etc.
The error message is uninformative:
einarr@barium:~/gpgtest$ LANG=en gpg2 passwd.gpg
gpg: can't connect to the agent - trying fall back
gpg: encrypted with 4096-bit RSA key, ID 9A6EE054, created 2011-12-14
"Einar Ryeng <einarr@pvv.org>"
gpg: public key decryption failed: General error
gpg: decryption failed: No secret key
Is this a know problem (and if so, is there a known solution)? If not, how could I best
proceed to debug it?
I’m using GnuPG 2.0.18 on all of these computers. On Debian I installed it from apt, while I
had to compile it myself on ubuntu (IIRC, i used the source packages from Debian).
The lack of response here indicates that this problem may be local to my computers, which
is a good thing. Should be easier to fix that way.
Can anyone confirm that they get CryptoStick, GnuPG 2.0.18 and 4096 bit keys to work
nicely together for decryption?
By the way, my key layout is so that I only have subkeys on the CryptoStick, while the
private main key is kept offline. Not sure whether that influences on the problem,
though it really shouldn’t.
My impression is that just very few people use 4096 bit keys on the Crypto Stick. Hence, this key length is not so well tested as others and it is not unlikely that you discovered a bug. If you can’t get it solved and think it’s a bug, please report to the GnuPG User mailing list.
EDIT: I had a little Email-Exchange with Werner Koch on the gnupg-users mailing list recently. He recommends NOT using 4096 bit RSA keys with gnupg, since the current releases do not really
support them, but the current default of 2048bit key length. Since I also had some difficulties using the 4096 bit ssh authentication key from the card, I wiped the keys and installed a new set of
2048bit RSA keys now. This seems to work without greater difficulties, and I also could make good use of the instructions below to set it all up again with the new 2048bit RSA keys - the decryption errors should not happen with the shorter keys. There still is a problem with scdaemon - it appears to need an occasional kick in the ass now and then to continue working…
I can confirm that decrypting does not work with gnupg 2.0.19 (On Debian 64 bit, compiled from original gnupg.org sources).
I transferred a set of 4096 length subkeys to the card yesterday, but always got the “No secret key” message.
Today I gave up on the key (unfortunately, due to fact that the HOWTOs I found proved to be quite unclear on a few vital details of the process, I managed to loose the local secret key for good).
Next problem was that overwriting the keys with gpg2 addcardkey did not work, I always got an error with writing the key. So here is the (hopefully cleaned-up) process that should work:
Goals:
[ul] ]Secure secret Masterkey on truecrypted external medium/:m] ]Use subkeys for signing, encryption and ssh authentication from cryptostick/:m][/ul]
Preparation:
First, take a look at we.riseup.net/riseuplabs+paow/o … -practices for useful details of gpg configuration
addgroup scard
addgroup username scard
In /etc/udev/rules.d create 40-cryptostick.rules:
There is still something missing here, on removing/reattaching the stick the gpg-agent probably should be restarted, and I am not sure if the ENV parameters are totally correct or even needed, did not find any documentation for that.
Install a fresh gpg 2.0.19 from sources at gnupg.org
This is only needed in the case that the distribution provides an outdated version of gnupg2 (I had a useless 2.0.14-2).
[ul] ]Deinstall the gnupg2 package if installed./:m] ]Download the source code for the support libraries and gnupg2 from gnupg.org/:m] ]Verify the signatures and SHA checksums. There might be outdated keys from Werner Koch on some packages./:m] ]Build and install the libraries/:m] ]Build and install gnupg2/:m][/ul]
The following only to avoid popup windows asking for PINs and passphrases:
2. Installed pinentry-curses
3. In .gnupg/gpg-agent.conf:
pinentry-program /usr/bin/pinentry-curses
In .bashrc:
export GPG_TTY=$(tty)
Stop the running gpg-agent, if any
sudo pkill gpg-agent, change Xsession config from /usr/bin/gpg-agent to /usr/local/bin/gpg-agent or in autostart or wherever it might be invoked on session start… DO NOT uncomment or add “use-agent” in ~/.gnupg/gpg.conf - this will make gpg1 try to use gpg-agent, too - so the decrypt workaround (see below) does not work anymore! Instead, remove
the use-agent switch from /etc/X11/Xsession.d/90gpg-agent. See below for complete source.
[ul] ] /usr/local/bin/gpg2 --export KEYID/:m] ] /usr/local/bin/gpg2 --export-secret-keys > savseckeys.gpg/:m] ] /usr/local/bin/gpg2 --export-secret-subkeys > savsecsubkeys.gpg/:m] ] For good measure, tar the .gnupg folder and the saved files and put them on a Truecrypted external device./:m][/ul]
Test
[ul] ]/usr/local/bin/gpg2 -e testfile → produces testfile.gpg SUCCESS/:m] ]/usr/local/bin/gpg2 -d testfile.gpg → ERROR/:m] ]/usr/bin/gpg -d testfile.gpg → Asks for PIN → SUCCESS/:m] ]/usr/local/bin/gpg2 --clearsign testfile.gpg → Asks for PIN → SUCCESS/:m][/ul]
So the problem seems to be that for some reason gpg2 neglects to ask for the PIN and so does not have access to the secret key.
This really looks like a bug in the whole gpg /gpg-agent / scdaemon mess to me.
Next, here is how to make ssh work with the authentication key on the card:
Edit /etc/X11/Xsession.options, put a comment ‘#’ in front of use-ssh-agent
DO NOT uncomment or add “use-agent” in ~/.gnupg/gpg.conf - this will make gpg1 try to use gpg-agent, too - so the decrypt workaround does not work anymore!
Change /etc/X11/Xsession.d/90gpg-agent like follows (remember, installed gpg in /usr/local/bin above)
: ${GNUPGHOME=$HOME/.gnupg}
GPGAGENT=/usr/local/bin/gpg-agent
PID_FILE="$GNUPGHOME/gpg-agent-info-$(hostname)"
if test -x $GPGAGENT &&
{ test -z "$GPG_AGENT_INFO" || ! $GPGAGENT 2>/dev/null; }; then
if -r "$PID_FILE" ]; then
. "$PID_FILE"
fi
# Invoking gpg-agent with no arguments exits successfully if the agent
# is already running as pointed by $GPG_AGENT_INFO
if ! $GPGAGENT 2>/dev/null; then
eval "$("$GPGAGENT" --daemon --enable-ssh-support --write-env-file="$PID_FILE")"
fi
fi
kill any running gpg-agent or ssh-agent, log out to restart the XSession
ssh-add -l shoud show the authentication key fingerprint, something like
ssh-add -L should show the matching public key, copy that.
put this key in the .ssh/authorized-keys file on the remote host
ssh login@remotehost → Asks for Pin → SUCCESS
Finally, store away the secret master key following the instructions from wiki.debian.org/subkeys, starting with item 5 after copying the.gnupg directory to your truecrypted masterkey device:
Test again before purging anything you might regret
[ul] ]/usr/local/bin/gpg2 -e testfile → produces testfile.gpg SUCCESS/:m] ]/usr/local/bin/gpg2 -d testfile.gpg → ERROR/:m] ]/usr/bin/gpg -d testfile.gpg → Asks for PIN → SUCCESS/:m] ]/usr/local/bin/gpg2 --clearsign testfile.gpg → Asks for PIN → SUCCESS/:m] ]ssh login@remotehost → Asks for Pin → SUCCESS/:m][/ul]
If everything works, remove any temporary copies from the machine.
