Page MenuHome GnuPG
Create Task
Maniphest T5585

Passphrase File Carriage Return New Line \r\n Issue in Windows
Open, NormalPublic
Actions

Description

gpg is doing the wrong thing (I claim) regarding carriage returns and new lines \r\n in passphrase files in Windows.

If you create a passphrase file in Windows you can easily end up with \r\n at the end of the line. gpg seems to be ignoring the \n but leaving the \r as part of the passphrase, leading to confusion.

Here is my version info today 2021/07/31:

gpg (GnuPG) 2.2.28
libgcrypt 1.8.8
Version Gpg4win-3.1.16

I am using Windows 7 with mingw as the command line.

In writing a script to automate the encryption processfor a bunch of files, here was the first test with a single file:

% gpg --batch --passphrase-file ppfile.txt -c myfile.txt

ppfile.txt contained one line:1234

When I tried to use Kleopatra to decrypt the file I got:

gpg: AES.CFB encrypted data
gpg: encrypted with 1 passphrase
gpg: AllowSetForegroundWindow(4264) failed: Access is denied.
gpg: decryption failed: Bad session key

Here is the hexdump output of ppfile.txt:

00000000- 31 32 33 34 0D 0A [1234.. ]

So is my passphrase 1234\r\n? No. It seems to be "1234\r". This worked:

% gpg --batch --passphrase $'1234\r' --decrypt myfile.txt.gpg > myfile-decrypted.txt

If gpg is going to ignore the \n it would seem appropriate to also ignore \r.

Details

Version
2.2.28

Event Timeline

bluepost created this task.Sep 2 2021, 4:46 PM
• werner claimed this task.Sep 2 2021, 7:25 PM
• werner triaged this task as Normal priority.
• werner added projects: gnupg, Documentation.
• werner added a subscriber: • werner.

I see that problem but gpg has traditionally not interpreted the passphrase in any way. Right, for Windows we could strip the CR but I fear that this might break other users scripts/passphrases. However there should be a warning in the manual.

Thanks for the well written report.

bluepost added a comment.Sep 2 2021, 8:49 PM

I'm guessing gpg in Unix has stripped the \n if present? I don't have access to a real Unix system at the moment.

Understand your hesitancy to change and documenting would be good. I did post a note on stackexchange.

• werner added a comment.Sep 3 2021, 8:42 AM

Yes, we read up to the first LF. This has been the traditional way of PGP2 and is still used by mail programs like Mutt.

As always I have to remark that it is better to remove the passphrase from the key than to supply it by a script to gpg. After all it is easy for an attacker to get the passphrase if it is stored somewhere and thus the passphrase protection does not make sense.

ikloecker added a subscriber: ikloecker.Sep 3 2021, 9:57 AM

The OP wants to do symmetric encryption. This isn't about the passphrase that protects a key.

Nevertheless I agree that storing a passphrase in a file on disk even if only for a short time should be avoided. In the end using public key encryption may be a better solution because then the machine that does the encryption only needs to know the public key. It really depends on the use case.

bluepost added a comment.Sep 3 2021, 8:19 PM

I think the behavior makes perfect sense for Unix but the default delimiter for .txt in Windows is \r\n.

I use vim for Windows and you have to work to get vim to not leave a \r\n at the end of line. Not hitting the return key on your keyboard before saving isn't enough. You still get \r\n.

Strangely, with humble Windows Notepad, if you type in 1234 and don't hit return and then save, you get a file with just 1234 and no \r or \n.