Windows 11 and Kleopatra not working

Gpg4win help-en
1

I’m using the same version kleopatra – Version 3.2.2.231170 (Gpg4win-4.3.1) and Windows 11. I cannot decrypt certain files with Kleopatra, see below for error. I can decrypt manually and force this, but this doesn’t work well when I have a bunch of files to decrypt. I think it has something to do with the CAST5, but I’m not sure and I’m not sure how to fix this.

gpg: enabled compatibility flags:
gpg: public key is xxxxxxxxxxxxxxxx
gpg: using subkey xxxxxxxxxxxxxxxx instead of primary key xxxxxxxxxxxxxxxx
gpg: encrypted with elg2048 key, ID xxxxxxxxxxxxxxxx, created 2001-10-26
“NYHESC (CLDATA.DOE.736)”
gpg: using “CLDATA.DOE.736” as default secret key for signing
gpg: WARNING: cipher algorithm CAST5 not found in recipient preferences
gpg: public key encrypted data: good DEK
gpg: CAST5.CFB encrypted data
gpg: original file name=‘’
gpg: Signature made 11/25/24 03:30:13 Eastern Standard Time
gpg: using DSA key 7B5EBCA1D7E4B01A
gpg: issuer “[totw@pearson.com](mailto:totw@pearson.com)”
gpg: Good signature from “Pearson (CLDATA.DOE.NCS) [totw@pearson.com](mailto:totw@pearson.com)” [unknown]
gpg: WARNING: Using untrusted key!
gpg: binary signature, digest algorithm SHA1, key algorithm dsa1024
gpg: decryption failed: Invalid packet
2

Hi @Jim_Cozzy as far as I know the Invalid packet means that the (encrypted) data is corrupted so it probably cannot be fixed. Did you encrypt the data yourself or did someone sent it to you? Maybe you can ask them to encrypt and send it to you again.

3

It was sent to me from someone else but they are using my key to encrypt.

4

And when you encrypt a file and decrypt it again everything is fine?

5

I can decrypt manually, but cannot decrypt when using kleopatra

6

When I say I can decrypt manually it is from a
powershell prompt

7

But if someone uses your key to encrypt a file and you try to decrypt it it doesn’t even work when you are using gpg in the PowerShell? Do you know which program was used to encrypt the file?

And what if you set the home directory of GnuPG? Is the decryption (of the file which you encrypted yourself) successful then?

8

It does work in Powershell, but not in Kleopatra.

9

This was working fine before I updated my computer to Windows 11 and updated Kleopatra to Version 3.2.2.231170 (Gpg4win-4.3.1)

10

I should also add that even though these files are encrypted by someone else using my key, there is no extension on the end of the file. Not sure if that matters or not

11

Also note, I get the same error when doing in powershell, but powershell does decrypt the file

gpg --decrypt C:\Users\me\Desktop\HE8344Y2425.TRAN0133 > C:\Users\me\Desktop\HE8344Y2425.TRAN0133.txt
gpg: enabled compatibility flags:
# off=0 ctb=85 tag=1 hlen=3 plen=526
:pubkey enc packet: version 3, algo 16, keyid *********
        data: [2046 bits]
        data: [2048 bits]
gpg: public key is ***********
# off=529 ctb=d2 tag=18 hlen=6 plen=65569 new-ctb
:encrypted data packet:
        length: 65569
        mdc_method: 2
gpg: using subkey *********** instead of primary key *************
gpg: encrypted with elg2048 key, ID *************, created 2001-10-26
      "NYHESC (CLDATA.DOE.736)"
gpg: using "CLDATA.DOE.736" as default secret key for signing
*gpg: WARNING: cipher algorithm CAST5 not found in recipient preferences*
*gpg: public key encrypted data: good DEK*
*gpg: CAST5.CFB encrypted data*
# off=546 ctb=a3 tag=8 hlen=1 plen=0 indeterminate
:compressed packet: algo=1
# off=548 ctb=90 tag=4 hlen=2 plen=13
:onepass_sig packet: keyid ************
        version 3, sigclass 0x00, digest 2, pubkey 17, last=1
# off=563 ctb=cb tag=11 hlen=2 plen=0 partial new-ctb
:literal data packet:
        mode b (62), created 1725956409, name="",
        raw data: unknown length
gpg: original file name=''
gpg: zlib inflate problem: invalid literal/length code
12

@bernhard do you have any idea what could cause this problem? Of course it’s now harder to find the reason because Gpg4win and Windows were updated.

@Jim_Cozzy a new version of Gpg4win is available. Maybe you could try that one in the mean time.

13

and

:literal data packet:
mode b (62), created 1725956409, name=“”,
raw data: unknown length
gpg: original file name=‘’
gpg: zlib inflate problem: invalid literal/length code

let me assume that something is not completely right when decompressing the decrypted data. If this is the case gpg should give a error condition and maybe this is the case why kleopatra is not completing the decryption. If there is something wrong, the data should not be fully trusted.

There are two possible sources of problems:

  • It really is the compressed part that is somehow wrong or the decoding code. Next steps for analysis: Find out which software the sender is using in particular. In order to be able to create a test case. Or find a previous GnuPG version that shows something different there.
  • The error / warning code handling between GnuPG and Kleopatra could be improved. However it seems better to not present a result of an operation that was not fully successful.

As for testing old versions. You could use a Windows Virtualbox image and then start with and way earlier Gpg4win versions and then use binary search for the version where the change has happened.

Noting that your keypair seems to be quite old. A potential constructive way forward would be to create a new keypair and see if your communication partner’s software handles it well, and the problem is gone.

14

Just funny that only thing that has changed is that my computer was updated to Windows 11 and so Kleopatra had to be updated to Kleopatra
Version 3.2.2.231170 (Gpg4win-4.3.1)

15

There must be a difference somewhere. Why was it needed to update Kleopatra then?

16

Hi!

Given that you get a “Good Signature”, the decrypted data is actually
valid and has not been tampered with. You get an error from Kleopatra
because after decryption and signature verification the decompressor
fails or is in an unexpected state. Older versions of Kleopatra did
not get hold of such a final error code but this has been changed with
the new version. If you run the decryption on the command line and
add the option

--status-fd 2

you will likely see a FAILURE status code with a code for invalid
packet for general error. That is what Kleopatra sees and considers
that something is wrong. Which is actually the case but because of
the Good Signature this is harmless.

The failure is most likely on the sending side; it would be
interesting to see which GnuPG version is used over there.

Background: The composition of a message is this:

Encryption layer
  Compression layer
     Signature layer
        Data layer (Literal Data packet)

The signature covers the data. The compression is done over the
signature and the data and the encryption is done as the outer layer
after compression. This is all done in a pipeline, thus while gpg is
writing the decrypted data and checking the signature it is still
reading from the compression layer and the compression layer is fed
from the decryption function which processes the encryption layer.

1 Like
17

Thank you, I got the warning on the command line when using the option --status-fd 2, but it did decrypt the file.
gpg --status-fd 2 --decrypt C:\Users\me\Desktop\HE8344Y2425.TRAN0133 > C:\Users\me\Desktop\HE8344Y2425.TRAN0133.txt

18

BTW, If you have any problem you should then add the option -v (or --verbose) which will give more detailed error diagnostics. The --status-fd thing is for autmated use as for example done by Kleopatra/

19

Could it be in praxis that someone added some encrypted data at the end, which then is confusing the decompression?

20

No, because we have authenticated encryption. That is the final
encrypted checksum would have detected this.

Shalom-Salam,

Werner

1 Like