PGP vijf

software, security, pgp, email

If you search for email encryption on the f-droid ‘store’, you’ll find pEp, which stands for pretty easy privacy. As I documented here earlier, currently securing email isn’t easy. Even when you know what a public-private keypair is, you rely on a wide variety of software interfaces to present a consistent view on encrypted email, which of course is not consistent. In virtually all clients you need to go through a rather laboreous key creation procedure, where you must ensure that your pgp client and mail client are aware of eachother and so on. Then, you often need to find the other persons public key yourself (some clients don’t search automatically, only if you press a button, sometimes hidden in a settings page). Then, you must usually enable encryption manually for every email.

pEp aims to simplify that workflow. Using Autocrypt and a set of defaults, it wants to remove all of the manual labor described above. It is a client-side workflow, so a client can either support it or not. The basic workflow is as follows:

  1. In pEp clients, a keypair is generated automatically and enabled automatically. No work needed. On the Android app, you may wonder why you must wait a few minutes when you setup a new email account: it is precisely because it generated the keypair upon setup.
  2. Every outgoing email includes your public key. Each receiver therefore can, if they either use a pEp client or release you just send them your public key, use it to both send you encrypted mail and send your their public key. With both ends using pEp clients, this indeed worked flawlessly.
  3. Note that pEp, after it detected the receiver supports pEp too, will encrypt the subject line as well. It can also encrypt all message on the (IMAP server) for your eyes only (untrusted server).
  4. Note that keyservers aren’t used in the pEp workflow; it’s all peer to peer by design. I think this is both because it enables ephemeral keys which to my understanding is currently seen as prefered over the old style of keys for life or until expiry. This does not mean keyservers can’t be used to lookup keys: sending to a (previously uncontacted) user with a published key (on the usual keyservers) it detected this after a few seconds and offered to encrypt right away. This is a very nice backward compatibility. However, pEp clients seems to send their message in the pEp way in either case, which is that the email subject and body are empty, and the message (which includes the subject) and public key as sent as attachments. So, some clients may provide different UX for message in attachments as opposed to inline.

Clients include an iOS and Android app (based on K9mail), a Outlook plugin and the encryption add-on for Thunderbird, Enigmail, had a v2.0 release almost a year ago which renamed it Enigmail/pEp. So, that’s not bad. Here’s the good news: it worked! The bad news: if you use multiple devices/clients (and who doesn’t), things get messy fast. Any pEp client generates new keypairs upon setup, so you must move one keypair between devices. I forgot to mention that you can use your self-generated keypair that you were already using. However, at least in the Android app, there seems to be no way to remove the defaultly generated key, so prepare to accumulate many keys over time. This is of course by design (ephemeral keys), but mind that (especially in untrusted server mode), you’ll need to back them all up/transfer them everytime. Let’s go back to that topic: key transfer. If you’re using multiple devices and clients, you’ll need to have one keypair available everywhere, because otherwise other clients will get confused (they’ll encrypt with their last seen public key from you, and may give a warning if you change keys, after all, that may indicate you being compromised). So, Autocrypt provides a mechanism for key transfer, which I suppose is what pEp uses. In Enigmail, I could see one key transfer procedure, pEp on Android offered two (pEp and OpenPGP transfers seperate). Let me cut an hour story short: none of them worked. I saw many mails flying up and down and I followed instructions a best I could, and in various ways so as to ensure I tried various interpretations of the instructions. Here UI across clients really comes to a head: the intructions couldn’t always be followed exactly because different clients have different UIs. For instance, Kmail has a button to add you public key, but in Enigmail in pEp mode, the Thunderbird option does not work (the pEp part of Enigmail seems to have its own parallel key storage). By default, it should be sending its public key, but it hides all of that such that I can not (easily) verify what I’m sending. The other issue is the number of keys: the UI (Enigmail or Android) do not provide feedback on which key is being used for encryption, while that is of course important, and is underlined by the key transfer message send by the pEp client itself. I tried to use a non-pEp client, which does provide this feedback on which keys are used, but without success.

In the end, I transferred my private key by file, which worked immediately. Urfff… So then, while in theory crypto should work kinda like the Signal protocol, still seems to involve a manual step. This is unfortunately not a procedure I can yet recommend to my parents, which I’d hoped to. If everyone would be using 1 device or client, I’d given a 10/10, but of course nobody uses 1 device or client, and if you still have to move your private key by hand, you’re nearly back to the old-fashioned PGP workflow. A pEp client then offers the nice default of sending out your public key everywhere and retrieving others public keys automatically, which is in itself also a win, but not as much as I had hoped. The pEp project seems pretty new, and not that well known, or well funded, so perhaps that will change with time and these issues will be improved. There is a community, a (nearly) complete manual and source.

One more thing. Kmail is really finicky with multiple email adresses, where ‘identity’, imap and smtp servers aren’t automatically linked up, and neither are ‘sent items’, ’trash’ or ‘concept’ folder. Even after setting them, this setting is often lost after a restart or so. Since Thunderbird and K9mail do this right, I’ve decided that, even though Kmails UI is otherwise pretty good, I’m going back to the bird. I also setup the autoconfig file, which works pretty nicely!

Small update: I disabled pEp in Enigmail. That means my private key and other peoples public keys are no longer found by default, I should run the setup wizard probably. However, I won’t. Even if pEp doesn’t solve key transfer yet, it does result in more PGP encrypted mails being sent. I did however discover that K9mail does not render attached message inline (i.e. you must open an app to read the msg.txt attachment). A strange default, because other clients such as Thunderbird and Kmail show (perhaps I should say render) the message inline, as oneee would expect. Therefore, I think I’ll simply stick to the pEp clients for now, which all in all do what they promise, apart from key transfer, which I can do myself. So far, it seems to be using my keypair and not the self-generated one consistently in both pEp Android or Enigmail.