Today, I solved a really troubesome problem for me: I couldn't access my GPG secret key. Which means that whenever I needed my secret key, for example when I wanted to sign some text and I typed in my key, I just received a "bad passphrase" error message. Not using GPG on a regular basis, I wasn't at all sure that I had used the right passphrase. However, today I recognized that I had another secret key for special usage, for which I had specifically written down the passphrase -- and which didn't work as well.
This finally convinced me that there was something else wrong beside a faulty memory of the passphrase. And indeed, when I tried signing a mail in Gnus/PGG, typing in the exact same passphrase as I had on the command line, everything was fine and the message got signed. But then what was the difference to using gpg from the command line? I was suspecting that some non-ASCII characters I have in my passphrase might not reach GPG as intended, so I started looking at the
locale settings. Some more experiments confirmed it: nowadays, my xterm (which is an lxterm really) is highly probably using a different key setting as it used to, after a re-installation of my desktop some time ago. I'm not too sure what it used to be, probably ISO-8859-1 (aka Latin-1) or ISO-8859-15 (aka Latin-9) or "C", but it's now using de_DE.UTF-8. Simply setting LANG to C inside a running xterm didn't work out as I hoped, probably because of the way the locale settings (probably LC_CTYPE) are used by xterm to set up keyboard handling. But when I start up a different xterm with LANG set to C in advance, i.e. do a "
LANG=C xterm &", gpg happily accepts my passphrase. Problem solved.
Moral of the story: charsets and input formats are a constant source of joy unless everything is unicode.