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
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?