GnuPG takes the passphrase as a verbatim string of bytes. It does not do any
recoding. I have not looked into the deatils why this is not working for you.

The workround is to use "gpg --passwd" on the old system to change the
passphrase to ascii-only, switch to the other system, and if you want change the
passphrase again.

FWIW: The PKCS#12 import of gpgsm has a similar problem. There is no agreeement
on how passphrases are encoded and thus all tools do whatever they like. To
mitigate that gpgsm has a list of common encodings and on import failure it
tries using a different encoding. If that encoding problem on gpg evolves into
a common problem, we might build a tool which tries to re-encrypt a passphrase.

----------Original Message----------
From: Pedro Coelho <pedro.msac@gmail.com>
Sent: Friday 19 June 2015, 14:55:41
To: gnupg-devel@gnupg.org
Subject: Issue 1998 Extended and Composed Characters on password.

Hi ,

Sorry to come up again with the same issue.
I posted some weeks ago an issue about gpg that I have detected while
working with gpg on Multiple/Cross systems.

This was passed to the bug tracking system as T1998.
I do not seem to be able to reply/follow-up on the bugtrack system so I
hope to contribute in here for the same issue.

I have tested to encrypt a file with a password that as several types of
characters, ascii, extended and composed.

As stated in the previous email listed below:

T1998

I was able to narrow down the problem to Composed Characters on the
password.

That is if one uses extended characters like the ones resulting from using
<altgr> or <altgr>+<shift> and try to decrypt the file on a different
OS/Computer, obviously the same keyboard layout must be present.
If the characters showing up on the CLI are the same as the ones used on
the password ... no problem for gpg to work correctly.

I made some tests passing the same file to Multiple Distros installed and
reached the conclusion that extended character support is not always
reliable to say the least ... but it can work.
For instance on Centos7 minimal with the exact same keyboard layout the
characters shown on display are not the same as in my default OpenSuSE 13.2
or Ubuntu. But once they are found gpg can decrypt the file.
That is an issue not of gpg but rather of the available mappings an Locales
on those particular systems. One as to simply be advised for those issues
in case of using gpg in multiple environments.

But problems do not stop there.
I have narrow down the problem of the decrypt bad key error to the Composed
Character.
If one uses composed characters problems keep showing up.

I used on the Same PC two sessions: One normal OpenSuSE KDE environment,
the other LXDE environment.
I noticed that on the LXDE session when using extended altgr/altgr+shift
chars I was able to decrypt my file.
The problem came about when dealing with Composed characters ... those
where a Symbol and a regular Character are composed.
Those who write in English most likelly never used such characters ... like
ã or õ. (don't even know if they even display correctly on your email
reader ... )

Those are a problem since in different systems Even with the same Locale
keyboard layout and Locale the use of a single composed chars can be
"misinterpreted".
On pinentry I've also seen for example when trying to enter a composed
character the box showed a double entry ...two chars (asteriscs) instead of
one ...

So this may indeed be a OS/Locale problem rather then a gpg problem ...