Use of composed characters and altgr utf-8 symbols on passwords.

[Pedro Coelho]

Hi,

I have an issue that I've detected today and searched the entire mailing
list and did not find an answer.
I hope I'm not wasting anyone's time.
I use OpenSuSE 13.1 64bits as my main distribution on Linux.
I encrypt on that same computer some files and my passphrase always used
both composed characters as well as altgr symbols.
Meaning utf-8 characters.

In this particular case I used symmetric encryption on a file, like this:

gpg -c --s2k-mode 3 --s2k-count 65011712 --s2k-cipher-algo AES256
--cert-digest-algo SHA512 file.txt

All is ok to decrypt the file when I use OpenSuSE KDE desktop even on other
computers I have.
What I have noticed tho is a strange behavior that should be of some
concern.
When trying to decrypt the exact same file on Other distros I always get
the Bad Key message!
Once the Same file is encrypted with a passphrase with no composed
characters And No altgr characters everything is ok! the file is decrypted
with no problem.
I've done some testing and used Centos 6 CLI mode only, Centos 7 with x,
Ubuntu (several versions) , Kali Linux, Tails ... you name it.

Worst.
On my computer I switched to a new session with LXDE as the desktop and ...
the result was the same!
The file I could decrypt in my KDE session I was not able to decrypt on the
same computer o on the LXDE session.
Same old bad key error.

Of course this may be realted to the way those chars are "interpreted"
between different environments. Or could this be a gpg bug?

Also I must alert you good folks that this is for me of Paramount
importance since increasing the character space of a passwrod is Hugely
important to increase the security.
It's also a big big hurdle if I can not have inter-environment
compatibility.
It really really is annoying ... and higly curtails a lot of the power
contained in gnupg ..

Can anyone try to explain why this happening ?

Best regards,
Pedro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150430/5aa8befe/attachment.html>