I suggested this a couple years ago, but it has yet to be implemented. There should be a way to simultaneously encrypt/sign clipboard content via Kleopatra. Currently, via Kleopatra, I can sign then encrypt, or encrypt then sign. But when decrypting, it takes 2 steps.
If I Encrypt it and then sign it, to undo this first you have to verify the signature (at which point it warns you it’s not encrypted) and then decrypt it (at which point it warns you that it’s not signed).
Alternatively if I sign it then encrypt it, to undo this first you have to decrypt it (at which point it warns you it’s not signed), and then verify the signature (at which point it wars you that it’s not encrypted).
Now if I start with GPA (not Kleopatra) I can simultaneously sign and encrypt clipboard content. If I then copy this signed+encrypted clipboard content from GPA, and run the Decrypt/Verify clipboard action on it in Kleopatra, Kleopatra will simultaneously decrypt the content and verify the signature. No combination of separately encrypting and signing clipboard content in Kleopatra causes the exact same output as the simultaneous Sign/Encrypt feature of GPA.
I just wish that Kleopatra had the same Sign/Encrypt clipboard content feature that GPA has, so that I don’t need to keep switching between the 2 programs. I want to be able to use one GUI for GPG4Win, and then stick with that one GUI. And Kleopatra is the one I want to use.
thanks for your suggestion. In fact we already have this on our todo list. ( https://phabricator.kde.org/T2040 ). This should then also use the new key selection dialog from the file encryption part, as the current clipboard key selection is also a not very user friendly.
Another feature I would like to see added is additional RSA key bit lengths available in Kleopatra. These should be 512bits and 1024bits (on the low end of the bit lengths available) and 8192bits (on the high end of the bit lengths available).
Note that we will probably not extend the RSA bit length options much.
For one part of the discussion see https://wiki.gnupg.org/LargeKeys
There is no compelling reason to allow new keys with 512bit and 1024bits.
And many GnuPG versions to not support 8k bit keys.
For all others there are still the expert options using the command line
and building their own version of GnuPG.
Note that this is best discussed on gnupg-devel@ oder gnupg-users@ as the defaults and settings come from GnuPG.
You wouldn’t need to add an extra description to the manual for just adding different bit lengths.
And by the way, Wikileaks uses an 8192bit key. This provides them extra security in case the government decides to try to intercept communications. When you load the Wikileaks PGP public key into GPG4Win, and check its info it shows that it’s a 8192bit key. So yes, keys of that length do work in GPG4Win.
You’ve seen the discussion I’ve pointed to: The extra security of longer RSA keys is doubtful. ECCs keys are probably the next step. The finer details are of interest for experts, which are usually fine to use the command line.
FWIW, you should (should because I have not tested it in a long time) be able to customize the Certificate creation wizard and the offered keysizes through config:
But for experimentation purposes I would always suggest using the command line. As bernhard says we don’t want to overly complicate Kleopatra’s user interface and it has been suggested that we drop non standard key sizes altogether and just offer the creation of “compatible (RSA)” keys and “modern (ECC)” keys without exposing ECC Curves or key sizes to the user.
The problem is it only lets you filter within the range of existing sizes. It doesn’t let you add new sizes outside that range. While they do appear in the selection list, the actual internal effect is truncated to be within the range already allowed (the range allowed prior to adding these lines to the config file). So 1024 is truncated up to 2048 (the smallest size allowed) and 8192 is truncated down to 4096 (the largest size allowed). In the menu, they show as 1024 and 8192, but when you actually generate the key, and then check the key’s properties, the key sizes are actually 2048 and 4096.
Please fix this in a future version of Kleopatra. If I specify it in the config file, the program should do it, without changing what I’ve told it to do. I hate it when software second-guesses the intent of the user, by refusing to allow the user to do what the user specifically told the software to do.
