Whenever I am trying to encrypt files which are already in compressed state, Kleopatra tries to again compress it and then encrypt it which makes it really slow. E.g. audio, images, video, zip, etc.
Could someone please help me on how to configure Kleopatra GUI to skip compression before encryption.
I don’t think you can do that with the GUI, since compression algo selection is based on the public keys preferences.
But I think that adding “compress-algo none” to %APPDATA%\gnupg\gpg.conf should do the trick.
Thanks for the reply. Though,
- I am not able to find gpg.conf file in %APPDATA%\roaming\gnupg\ directory. Should I create it myself?
- And if I add “compress-algo none” to this file, will it work with Kleopatra or will I have to use command line?
- Where can I select change the preference for algo selection for the public key? I own both private and public key.
re 1: if gpg.conf does not exist (in te right path), you can create it.
re 2: Kleopatra is a front-end to the crypto engine, gpg.conf changes the behaviour of the crypto engine, so it works for all front-ends (unless they override a parameter).
re 3: Consult the documentation, look for preferences in the command `–edit-key’ https://gnupg.org/documentation/manuals/gnupg/OpenPGP-Key-Management.html#OpenPGP-Key-Management
Thanks so much Bernhard for the detailed reply. This was really helpful.
I was able to disable compression in both ways, through gpg.conf and also through setting key preferences through command line(I wish there was a way to do this through GUI).
Though I experienced something strange in the encryption timings. When I encrypt files using command line e.g. “gpg --sign --encrypt ” it takes almost 25-50% less time than signing and encrypting file using Kleopatra GUI. Why is that so?
I coupld of other forums, I read that there might be a slight performance benefit while using command line but I did not expect it to be this much big.
Yes, that is a painful issue. Due to our architecture passing data through all the layers from the GUI back to GnuPG is really expensive in CPU time. I have looked into it from time to time but never got around to really improve that. The problem is that the GUI reads the data and passes it through several layers where it is copied in memory before it reaches GnuPG.
So yes, known issue that the performance of Kleopatra (GPGME) is bad on Windows. We will likely improve this in a future Version.
Thanks Andre for the prompt response. I would prefer using the CLI in this case.
Could you please let me know why the same file which is signed and encrypted with CLI and GUI have different sizes in the end?
I am also not able to sign and encrypt multiple files at the same time using CLI. Is there any workaround to this?
have you tried --multifile or “–encrypt files”
Although the idea is that for multiple files you run them through an archive command first.
Different sizes I can’t explain. How big is the difference? If the difference is small it can be just randomness in the encryption process.
Thanks for the reply Andre,
I have tried --multiple but it only works if I am trying to only encrypt files. If I want to both sign and encrypt, it does not work. It gives an error message saying it is one of the limitation. I think it might be in the pipeline for the development for now.
Sure, it is a good idea to archive multiple files before encrypting but it becomes painful when multiple files are in 10s of GBs and you want to decrypt just one of the file. It might become time consuming at that time so I prefer to individually encrypt large files.
Difference in sizes is really small while encrypted from CLI and Kleopatra GUI but encrypted file size stays consistent when encrypting it using the same method. So the minor size difference must be due to some overhead created by GUI.
Thanks so much for the help. I think I have all the info and answers that I was looking for.