I have tested something strange about Gnupg …
I encrypted a file in symmetric mode
gpg -c
and then noticed the same file did not open on Any other environment other then my desktop normal session … KDE.
I’ve installed OpenSuSE 13.1 64bits.
I tried to open the same exact file on a LXDE session and it did not work!
The strangest thing is that I’ve tested the same file on many other VirtualBox guest systems, and noticed one thing that is strange:
If one uses Composed Charaters like for example: ‘ó’, no matter how simple the password is … I could only decrypt the file under KDE.
I used VM guests like Centos, Debian, Ubuntu … you name it … none would Open the file!
If the password I used on KDE did not have the composed Characters … then I would be able to decrypt the file in any of the previously mentioned OS’s …
> If the password I used on KDE did not have the composed Characters …
> then I would be able to decrypt the file in any of the previously
> mentioned OS’s …
Then don’t use such letters… (I don’t).
Likely kde input is not the same as the other desktops.
Could very well be but if that is the case it’s a Security Problem since using gpg under something other then KDE reduces the number of characters to use.
Also it could be that they interpret composed characters in a different way. Note: I double checked every time, I was using always the exact same Keyboard layout/mapping.
So I find it strange it could be something like keyboards mappings type of problems.
If the latter is the case then it’s a problem of Portability of encryption … that is even more problematic.
Also the Same exact problem occurs when using utf chars … alt-gr key + some other key …
Truly Not good and if someone has the same problem and a solution … I would like to know about it …
I am not very well known with the products you use, but I assume one must be aware of the two aspects that could be the cause of the problem.
Composing is one way to enter characters (that are not show on the keys) using a keyboard. The composing keystrokes are translated into an Unicode point. It could be that the composing as you use it is not supported/recognised by all products you try to use it in. You could try to enter the characters using another method like copy/paste where the correct character is already there.
It could be that the composed character is translated into the correct Unicode point, but that storing/interpreting it (using UTF-8) is not supported by some of the products you use. E.g. when a product only supports the ASCII subset of UTF-8 encoded Unicode there is s problem. IMHO every product in today’s Linux should support it, but who knows?
I’ve been doing some more tests with both Composed characters and altgr characters and it’s hopeless !
The simplest of the passwords with Any of those types of chars is simply Not compatible between systems.
I’ve also tried Kubuntu and the results are the exact same.
I strongly suspect pinentry is the problem … but it would really really be important to have this matter sorted.
I consider this an Important Bug on the all gpg platform …
It could be.
But all distros I used were Linux … Super Standard stuff and they all support UTF-8 with no problems … the advantage of Linux is exactly that one …
I strongly suspect of pinentry tho …
I always tried to use CLI mode only but the pop-up always comes out.
Pinentry is the Default on all distros to work with gpg.
I also used Centos cli mode only and the results were the same. Also this Centos was booted with the correct keyboard layout, so no problems with using an incorrect keyboard mappings.
Also very important, my keyboard layout is always the same and I make a Copy-paste into the cli to See the password. All characters are Correct, no doubts there, double checked.
That is why I strongly suspect of pinentry.
Anyone can try and verify this.
Also this is a Huge Issue both in terms of Portability/Compatibility And Security … increasing the Character space makes your Password Much Much Stronger.
I would really hope someone could take a look at this issue … it’s a Show Stopper for so so many things …
On 2015-04-30 13:06, keyb user wrote:
> hcvv;2707547 Wrote:
>> Hope this helps analyzing.
>
> It could be.
> But all distros I used were Linux … Super Standard stuff and they all
> support UTF-8 with no problems … the advantage of Linux is exactly
> that one …
But passwords…
On UTF8 a single letter may be several bytes. Big problem.
> Anyone can try and verify this.
Well, I never use “foreign” letters in passwords. And I’m Spanish, we
have those letters. There are other places where they cause problems or
are not supported. One is Grub. Another is the password for encrypted
filesystems.
>
> Also this is a Huge Issue both in terms of Portability/Compatibility And
> Security … increasing the Character space makes your Password Much
> Much Stronger.
Assuming that internally they use long-chars, and not bytes, traditional
chars.
> I would really hope someone could take a look at this issue … it’s a
> Show Stopper for so so many things …
I also don’t use those utf chars on passwords other then on files.
I never used them on partition encryption or any other type of OS-related encryption.
I also speak and read Spanish fluently and there’s a lot of those composed characters. Many languages have loads of composed characters … it would be good if they could be used Between OS’es …
Also from a Standpoint of security it is a majoe Backlash if we can not use the full utf-8 character space between distributions …
One of the most important ways to increase security is to expand the char space.
Yup, could be … but it still seems to me like it’s pinentry .
I will report the issue on the gnupg bugzilla …
I will make sure the issue as never been addressed before …
If indeed it is an issue it as the potencial to affects a Huge amount of users.
Also, since I’m not a gnupg expert the way I’m encrypting the files could be an issue …
I always use:
> Also from a Standpoint of security it is a majoe Backlash if we can not
> use the full utf-8 character space between distributions …
> One of the most important ways to increase security is to expand the
> char space.
The rusty programmer in me cringes at the idea of implementing utf-8
support in passwords. It is a nightmare… oh, maybe I’m too rusty.
