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
“test1”
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
“test1”
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.