In an earlier post I tried setting up Autocrypt and detailed the process for my own reference, but also in the warrantless hope it might add a usable anecdote to how the procedure of setting up email encryption is prohibitively complex. Today I retried, with success. To be precise, this time I did not setup Autocrypt, but just PGP. I decided Kmail was a more pleasant (and fast) email client, but it does not supports Autocrypt. Incidentally, Kmail, together with Kontact, is a quite comprehensive PIM package, supporting things like CardDav/CaldDav in addition to mail. It even syncs calender tasklists. It is however slightly laborious to set up, not in the least because of the (I might not even be exaggerating) millions of settings. In that maze of settings, of course PGP was not missing, tempting me into retrying once again to set up things.
Kmail uses the Kleopatra tool to manage your gpg server/client/deamon. Get it? For reasons I don’t quite grasp,
gpg, an implementation of PGP, works as a background process continuously running, and ‘managing’ your keys. That means you import keys into it, be they your private keys or others public keys. I do not know if it is responsible for keyserver lookups, but I guess any process can retrieve public keys themselves and then simple add them to
gpg. Kleopatra is a tool to manage
gpg, so it can create new keypairs, import keys through a GUI interface. Incidentally, the gpg4win
distribution includes Kleopatra, so this very straightforward to use tool is not limited to Linux, and as Thunderbird (the Enigmail plugin rather) actually downloads
gpg4win for you when setting up, so perhaps using Kleopatra instead of the procedure that resulted in a bug detailed in that earlier post can be worked around. Todo later.
Kleopatra does not offer to generate a revocation key, but the help details how to generate one:
gpg --output revocation_certificate.asc --gen-revoke your_key
gpg asks you to give reasons for your revocation, indicating you are revoking the key straight away. I think it is not actually doing that (after all, the command generates the revocation key and saves it to a file). Confusing UI!
Once I generated my key with Kleopatra, it offered to submit it. After giving no feedback for about 30 seconds, a message popped up it had failed, and it included the http://keys.gnupg.net keyserver in its message. Doublechecking on their website, an account seems to be required, for which Kleopatra appears to have no UI. Also, it shows my old key as revoked, while as far as I know that key was never submitted here. So perhaps keyservers sync keys between them? Or the GUIs fails on key submission detailed in the earlier posts are even graver than I then described. Meanwhile, I have submitted my key by hand to <//pgp.mit.edu> and <//keyserver.ubuntu.com>. The former, after a few time-outs, now shows my key, but the latter does not, and allows me to resubmit, indicating a problem.
While not smooth, things are set up and I send myself an encrypted message successfully, so anyone may now lookup my key on <//pgp.mit.edu> and <//keyserver.ubuntu.com>, and send me your top secret stuff! What’s left is to instruct K9 to use my key and to perhaps retry Thunderbird but using Kleopatra as a workaround for the bug.