Kleopatra ignoring gpg.conf?

I want to disable compression as it drastically increases file encryption time and offers no real benefit. In %appdata%\gnupg I have gpg.conf with “personal-compress-preferences Uncompressed”. Using gpg cli I can encrypt a large test file in ~6 seconds, but using the windows explorer right click menu “Sign and encrypt” and just leaving the encrypt for me option it takes ~23 seconds.

I have rebooted to make sure no lingering processes was causing the issue, it didn’t help.

Actually I’m not sure what’s going on. Initially I was testing with video files that aren’t compressible, but I tested with some large plain text files and it seems like both gpg cli and kleopatra aren’t compressing the text file, but kleopatra is taking significantly longer.


First a tip: To inspect what is really going on you can use the command line with the --list-packets option


gpg --list-packets pure.css.gpg
gpg: encrypted with 3072-bit RSA key, ID 8CC999BDAA45C71F, created 2015-12-08
“Andre Heinecke aheinecke@intevation.de

off=0 ctb=85 tag=1 hlen=3 plen=396

:pubkey enc packet: version 3, algo 1, keyid 8CC999BDAA45C71F
data: [3072 bits]

off=399 ctb=d2 tag=18 hlen=2 plen=0 partial new-ctb

:encrypted data packet:
length: unknown
mdc_method: 2

off=420 ctb=a3 tag=8 hlen=1 plen=0 indeterminate

:compressed packet: algo=2

off=422 ctb=ad tag=11 hlen=3 plen=31945

:literal data packet:
mode b (62), created 1547624973, name=“pure.css”,
raw data: 31931 bytes

There you can see “compressed packet” if compression is used.

Indeed compression is a performance problem and I thought in the past for an algorithm to detect heuristically if compression should be used. Kleopatra respects values from the gpg.conf though because it internally just calls gnupg without a specific compression override.

Now regarding the performance differences. Kleopatra usually has a bit different performance because it has more interprocess communication involved and that takes a bit longer but not as much as you describe. So in general using the command line will be fastest as it involves no overhead.

I can take significantly longer though under some circumstances because in contrast to GnuPG it first creates the encrypted file in the users TMP directory and only on successful encryption moves it to the target place. If your home dir (TMP dir) is on a different network share or a different drive that can have a very big performance impact.

I just looked at it and Kleopatra currently has an option to change that behavior for decryption but not yet for encryption. We should add that, so I’ve opened https://dev.gnupg.org/T4323 for this. In the meantime if that is indeed your problem you need to use the command line :-/ (Or start Kleopatra with a different temp dir environment variable).

Best Regards,

I didn’t know about that file inspection option, thank you. Also thanks for going into details on the differences.

In my specific case my user temp folder (\AppData\Local\Temp) is on my main SSD so it shouldn’t have any performance issues. The file I was testing with was on a 2nd local SSD, but both are SSDs and the file was only 361MB so at most that should account for a couple of seconds extra time.

I did use the --list-packets command and it does show both are missing compressed packet in their output so they do seem to be using my config setting properly.

I did notice a couple differences in the two though. I created a test 4096 key, here is the output of the one encrypted with CLI gpg.exe

F:>gpg --list-packets test.mp4.gpg
gpg: encrypted with 4096-bit RSA key, ID E4253EA18F040838, created 2019-01-18

off=0 ctb=85 tag=1 hlen=3 plen=524

:pubkey enc packet: version 3, algo 1, keyid E4253EA18F040838
data: [4095 bits]

off=527 ctb=d2 tag=18 hlen=2 plen=0 partial new-ctb

:encrypted data packet:
length: unknown
mdc_method: 2

off=548 ctb=ae tag=11 hlen=5 plen=25459171

:literal data packet:
mode b (62), created 1547770608, name=“test.mp4”,
raw data: 25459157 bytes

Then the one encrypted with Kleoptra

F:>gpg --list-packets test2.mp4.gpg
gpg: encrypted with 4096-bit RSA key, ID E4253EA18F040838, created 2019-01-18

off=0 ctb=85 tag=1 hlen=3 plen=524

:pubkey enc packet: version 3, algo 1, keyid E4253EA18F040838
data: [4094 bits]

off=527 ctb=d2 tag=18 hlen=2 plen=0 partial new-ctb

:encrypted data packet:
length: unknown
mdc_method: 2

off=548 ctb=cb tag=11 hlen=2 plen=0 partial new-ctb

:literal data packet:
mode b (62), created 1547770619, name=“”,
raw data: unknown length

Both are using the same file, just renamed it to test2.mp4 before encrypting it using Kleoptra. The differences being the data having 1 bit different, 2nd offset line having some differences between the two and the test2 missing the name and data length. I doubt that has anything to do with the performance issues. My googling let me to rfc1991 for decoding the CTB (cipher type byte) and if I did it right then the CLI is using CTB

10 - normal CTB
1011 - literal data packet
10 - 4-byte packet-length field

and Kleopatra is using

11 - reserved for future experimental work
0010 - signature packet
11 - no packet length supplied, unknown packet length

Not sure why and I doubt that’s the performance issues, but was the only difference I could find and figured I’d mention that.

Off topic, about a compression algorithm that I think would be great is LZ4, I believe it has a builtin abort if it detects uncompressible data, is very fast and offers decent compression. Though you would need that added to gpg itself so not really helpful for Kleopatra.

Have you tried it if you place the file before encryption on the first SSD? Just to see how much (if any) difference it makes.

Also when using Kleopatra GnuPG is fed data and receives data in chunks the chunksize is probably not optimal for your setup with the SSD’s able to provide data faster then the Interprocess communication overhead can handle it, causing the delay.

There is Room for improvement :slight_smile:

Regarding the compression algorithm:
Any new algorithm would need to be added to the OpenPGP Standard to be interoperable.
( See: https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-06#section-9.4 )

You might want to suggest that on the OpenPGP Working group list ( openpgp@ietf.org ) but I doubt that any new algorithm will be accepted because it will complicate implementations.

Btw. the current standard is rfc2440, rfc4880 is the next iteration of the standard which is currently worked on.

Tested using my 361MB video file again, but with it on my desktop. No real difference, CLI took ~6 seconds and Kleopatra ~22. For timing CLI I start the click as soon as I hit enter and end once the command prompt returns. For Kleopatra I already have the right click menu open and only Encrypt for me checked. Then start the clock as soon as I click Encrypt and stop it right when the progress bar goes away.

Looking at CPU usage gpg stays at a consistent 25% through it’s entire process and Kleopatra fluctuates from 27-30% the whole time.

Didn’t think about Kleopatra having to feed data to gpg, that sounds like a reasonable cause. Still surprised it makes that big of a difference.

Thank you for the help, doesn’t seem like anything can be done. At least I know everything is working properly with the config.