Gpg4win Can't Decrypt -- Bad Session Key -- Symmetric

Today I got the message gpg: decryption failed: Bad session key when trying to decrypt my first test file.

I have several hundred files that I want to symmetrically encrypt all with the same passphrase, no user id, no public/private key etc. I want anybody with the passphrase to be able to unlock the files 10 or 20 years from now.

I’m still running Windows 7 and using a Unix shell courtesy of Mingw. Here is my version info today 2021/07/31:

gpg (GnuPG) 2.2.28
libgcrypt 1.8.8
Version Gpg4win-3.1.16

In writing a script to automate the encrpytion process, here was the first test with a single file:

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

ppfile.txt was created with VIM for Windows, and 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

Some of you are probably jumping ahead to say that my passphrase is not really “1234”.

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”. Maybe gpg is smart enough to ignore the \n in Unix files, but should also ignore the \r\n in Windows files? This worked:

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

I did run the same batch encrypt line from the Windows command line. The same result occurred. Notepad, the humble Windows text editor, will deliver a file free of \r\n if you don’t physically hit carriage return before hitting save.

I was about to ask for help on this forum when the solution presented itself. Is it correct?

That sounds reasonable.
The entire content of the password file is considered to be the password, so any editor which leaves invisible content is going to cause problems.

Seems you figured out how to do it in Windows, by not hitting Enter before saving after typing the password.

The entire content of the password file is considered to be the password, so any editor which leaves invisible content is going to cause problems.

Not exactly – gpg.exe for Win is ignoring the end of line, \n, but retaining the carriage return, \r, as part of the password. My suggestion was that gpg should ignore both or retain both.

Hi,
yes, this looks like it would be an improvement if \r was also ignored.
Next step would be to open a report on dev.gnupg.org .

Best,
Bernhard