After the 2013 Snowden revelations, there has been a push to make email more private than it currently is (which is, essentially, like writing on a postcard). The big guns, Google and Yahoo, have wowed to make their respective email systems end-to-end (E2E) encrypted but progress has been slow. The official page about the Google effort has not been updated for months (as of June 2015). In this article, I go over some options available today, while we wait for that final solution that, at this pace, might still take a while to come.
There are dozens of options, but here I am going to review only a few that are better known in order to compare their features. Here I compare the following: Enlocked 2, Virtru,Proton mail, Mailvelope and, of course, my own PassLok. All of them promise to make encryption easy, at least compared to what it used to be. Some take pretty drastic shortcuts in order to achieve this, as we shall see. They all perform encryption and decryption at the user end, rather than at the server, since otherwise the server would have access to the plain content, with the consequent risk if subpoenaed or simply hacked. They all run the encryption code in JavaScript, which is a no-no for some, but currently there is no other way to run code locally on a browser.
Given that they all do the essential thing in some way or another, I looked into other desirable features of an end-to-end email system. Here’s a description of each feature:
- No need to change address. It’s a hassle if you need to use a different email address in order to have privacy. Here a Yes means that you can continue using your current email provider and address, and still obtain the benefit of encryption.
- Provider doesn’t store secrets. If it does, there’s always the danger that they’ll be forced to reveal them. Now, some providers store them in encrypted form, which is better, but still they’re storing something sensitive essentially forever.
- Provider cannot read email. As ludicrous as this may sound, at least one of the providers featured in this article is able to read your emails, or enable someone else to do so. We are assuming the encrypted content is easy to intercept.
- Account not required. Because some of us are paranoid enough to prefer not being forced to make an account anywhere, to prevent being tracked when we use it, or whatever other reason.
- Encrypt attachments. Not all we send is text. Often the sensitive information will be a picture, document, or any other kind of file. Encryption should be able to handle this.
- Encryption visible. A study published in 2013 showed that, for the time being, users prefer to see their messages in encrypted form at some point, in order to be assured that they are indeed encrypted before they send them out. They were willing to go as far as cutting and pasting the material in order to get this. This feature does not need to be on 100% of the time, but at least as an option.
- Encryption can be disguised. A number of users need encryption because they fear they are under surveillance. They would be even happier if they could make their emails and attachments appear as if they were not encrypted at all. This is called steganography, and at least one of the systems reviewed adds this feature to the mix.
- Forward secrecy. This means that the encrypted content remains secure into the future, even if the encryption key or the user password is obtained by an enemy. This is considered essential for instant messaging apps, and would be nice if email could also pull this trick, perhaps as an option.
- Multi-platform. It is no good if users need to use a particular kind of device (PC, iPhone, whatever) in this fractioned market.
- Portable across machines. This means that a give user should be able to use his/her E2E encrypted email on different machines, possibly of different kinds, with a minimum of risk and hassle.
- Multiple identities. What if several family members or coworkers share a computer? Can they keep privacy from each other? What if you’re schizophrenic or have multiple personalities?
- Open source. A deal-breaker for many, if it is not. Some of us feel a lot more reassured if the underlying code is available and experts can subject it to scrutiny.
- Crypto engine. There are a number of cryptographic engines out there, some more recent than others, but all the systems presented here use an engine that has accumulated at least ten years of scrutiny.
So here’s the comparison as a table. Yes is good, No is bad. Some entries have a footnote right below the table.
| Features | Enlocked 2 | Virtru | Proton mail | Mailvelope | PassLok |
|---|---|---|---|---|---|
| No need to change address | Yes1 | Yes1 | No | Yes1 | Yes |
| Provider doesn’t store secrets | No2 | No | No2 | Yes | Yes |
| Provider cannot read email | Yes | No | Yes | Yes | Yes |
| Account not required | No | No | No | Yes | Yes |
| Encrypt attachments | Yes | Yes3 | Yes | No | Yes |
| Encryption visible | No | No | No | Yes | Yes |
| Encryption can be disguised | No | No | No | No | Yes |
| Forward secrecy | No | No3 | No | No | Yes |
| Multi-platform | Yes5 | Yes5 | Yes | No | Yes |
| Portable across machines | Yes6 | Yes6 | Yes | No | Yes |
| Multiple identities | No | No | Yes | No | Yes |
| Open source | No | No | No | Yes | Yes |
| Crypto engine | PGP | AES | PGP | PGP | NaCl |
| Overall score (# of yes) | 5 | 4 | 5 | 6 | 12 |
- The app works only with certain email providers, not all of them
- They do store encrypted private keys, hence the bad score
- Separate encryption and delivery from server
- They deny access to the encryption key (paid feature), but the key is not deleted
- Browser plugins plus apps in iOS/Android stores
- User secret data saved in servers (encrypted) enables this
Now a short description of each E2E provider, and why they got these scores.
Their first version got slammed by reviewers because it was doing the encryption on a server instead of the client. This meant that their server got to see the plain text of your private stuff, even though they promised (who doesn’t?) that they didn’t store it. Enlocked 2 is a browser plugin (standalone mobile apps exist) that performs PGP encryption on the client. Their server holds each user’s public key so it can be sent to other users who want to encrypt messages for the owners of those keys to read. The plugin automatically retrieves each public key belonging to a recipient in an email and uses it to encrypt the content before sending the encrypted result to the actual email provider. Because it is a plugin, it only works with Gmail, Yahoo mail, Outlook, and a handful more.
In order to achieve portability, Enlocked also stores and serves the user’s private key, previously encrypted by his/her password. This is a problem, since compromising that password or choosing a bad one (Enlocked accepts bad passwords without complaint) makes all your encrypted emails readable by Enlocked or those to whom they give your private key.
Enlocked is a commercial service, which costs $9.99 every month for sending 100 messages, and goes up from there. You can sign up for a free account, though, which allows you to decrypt an unlimited number of messages and encrypt 10 messages every month. Their system seems to be glitchy: I’ve tried for several days to make a free account without success, leading only to error screens that instruct me to contact support (without any link to support, though).
On the surface, Virtru behaves very much like Enlocked. They have slick plugins and mobile apps. They encrypt text and attachments. You only need your account password to use it anywhere you go. The difference is that they use symmetric encryption (256-bit AES) instead of asymmetric encryption (PGP). When you encrypt something, you send the actual, per message encryption key to Virtru, and they store it so they can give it to the recipients of your encrypted message. The whole process is quite automatic and makes it possible for new users to be added in a flash, since no initial key generation and exchange process is needed.
The downside is that they can read your encrypted messages, if intercepted (they are sent through your regular provider, from a limited list of supported ones), and enable anyone who asks nicely to do so. This should be a deal breaker for anyone who has real confidential material to protect. To make matters more egregious, they charge for “forward secrecy”, meaning that Virtru promises to no longer give the decryption key to anyone except you (and, possibly, government agencies).
If you don’t want the paid features, Virtru is free to use, though making an account is a must. A Pro account with the extra features will normally set you back $4 a month.
Proton Mail is Enlocked with an email server thrown in. When you sign up for Proton Mail, you sign up for the whole thing, and you get a username@protonmail.ch email address. No way to keep using your old address except by forwarding. Proton Mail requires the user to memorize two keys: one is for logging into the email server and getting your emails, plus obtaining the PGP public keys of other users automatically; the other is for encrypting your PGP private key, which is stored in their server so you can use different machines. Since they must know your login key in order to give you access, they’d also be able to read your encrypted mails if both keys were the same, hence the need for two separate keys.
Proton mail is accessed strictly as a website, so no plugins or mobile apps are involved. Interestingly, this approach makes it accessible from any device, running any operating system.
Proton Mail just finished beta and is available for signups, everything is free, though not open source. I believe that Google’s and Yahoo’s E2E solutions, when they come, will end up looking a lot like Proton Mail.
If Proton Mail was Enlocked plus a mail server, Mailvelope is Enlocked minus a key server. It uses PGP like the other two, but key generation is kept strictly to your machine. The user is responsible for distributing his/her public key to others, and for safeguarding his/her private key, which is locally stored encrypted by a password. Mailvelope is only available as a Chrome extension and off the box it is limited to Gmail, Yahoo mail and a couple more, though apparently you can configure other clients manually (I didn’t try). Integration with those is quite slick, however, as Mailvelope detects encrypted incoming emails and offers to decrypt them if only you supply the password.
This extension may be all that many people will ever need, so long as they don’t use encrypted email with a lot of people (public key entry and selection is a bit involved) and don’t need portability (settings don’t sync across machines).
Obviously it was a foregone conclusion that PassLok was going to be the winner in a comparison made by its own developer. I won’t dispute that, but the fact remains that PassLok has all the desirable features on the list. You can use it with your existing email (in fact, with any program at all). It doesn’t store your content or even anything secret. It doesn’t talk to servers so you’re not making any account anywhere. It handles files as well as text. It runs as a Chrome plugin, iOS/Android app, or just as a webpage that gets completely cached so you don’t even need an Internet connection after the first time. It includes a full complement of text and image steganography tools so your encrypted material can slip undetected. In its Chrome app incarnation, it even syncs all your stored public keys (which are not secret, but may be hard to obtain again) using Google’s servers. It is possibly the only web app available today capable of making a self-destructing message, where the key needed to decrypt it disappears from the face of the earth as soon as it is read once.
But it must have some defects, right? C’mon!
A lot of PassLok’s security lies in the fact that it is self-contained code, and precisely this is why some things are harder to do than in other systems. PassLok does not interact with email clients, and so the user must manually copy and paste the encrypted material between PassLok and whatever email client you are using. This is a hassle, but it has the advantage that you know without a doubt that your data is encrypted before it gets to your email. Some email providers, like Google, log every keystroke you type into the compose window, so it is important to encrypt your messages before the email program sees them.
PassLok does run a server to help users obtain other users’ public keys. It is called General Directory, and currently it is manual rather than automatic so that the main PassLok code is isolated from contact with any server. A lot of things in PassLok are automatic, but nothing is forced on the user. If the user decides not to make public his public key, but rather send it to a selected few, that’s okay with PassLok. Most PassLok users actually do this. They are a paranoid but dedicated bunch.
Thanks for the article — as an encryption user, it’s nice to see all these encryption options compared. I think you have a couple details wrong for Virtru, though. Forward secrecy doesn’t mean, “I’m giving away your secrets now, but won’t give away your secrets in the future.” It means that the encryption is designed such that, if one set of keys is compromised in the future, it won’t allow the cryptanalyst to decipher past email messages. It prevents someone from deciphering a session key and using it to read all your emails.
Forward secrecy is a standard feature of all Virtru encryption — not just the pay version (it’s not an unusual feature at this point, although not everyone uses it.)
The Pro features are things like rescinding emails (actually, rescinding the key so the recipient can’t read it), read receipt (which lets users see if an email has been read) and disable forwarding. But the Pro version uses the exact same encryption AFAIK — it just has a few extra features.
Also, my understanding is that Virtru can’t decrypt your email, since they never see the actual message — just the key.
Thanks for the comment, Yan. It seems, however, that Virtru users have no way to know that they are actually getting the kind of forward secrecy that you mention. After expiration, the Virtru server probably deletes certain keys so decryption becomes impossible, but users have no way to verify that this is actually taking place and that those keys are not being saved somewhere for future use. Assurances by the server are simply insufficient. I consider this a fatal flaw, shared by all server-based encryption systems, not just Virtru.
Passlok sure sounds a lot like x.509 [email] certificates used by S/MIME to encrypt e-mails at the client end (which has been available for 15 years). Doesn’t matter what e-mail provider you or the other person uses since they are not ever involved in the encrypt/decrypt process. With an e-mail cert installed in your local client, you digitally sign your outbound e-mails to those recipients from whom you want to RECEIVE encrypted e-mails. When they get your digitally signed e-mail, that gives them your public key. They save you as a contact (to retain your public key). When they want to send you an encrypt e-mail, they use your public key and send to you. Only you have your private key (in your client, not up on the server) to decrypt. If you want to send someone else an encrypted message, they must’ve invited you to do so by sending you a digitally signed e-mail (and you save them as a contact so you store their public key). This requires the sender use a client that supports S/MIME so they can digitally sign their outbound e-mails and recipients with x.509 capable clients that can record your public key in the contact data. MS Outlook is one of those. You do have to get an e-mail certificate, like a free one from Comodo. Just be wary of which web browser you use to signup for and install their cert. Firefox has its own private cert store while IE and Google Chrome use the global cert store. If you install the cert using Firefox, only Firefox (and maybe Thunderbird) can use that cert. If you use IE or Chrome then any app that uses the global cert store (see certmgr.msc in Windows) can use the cert.
What Passlok appears to do is make the process of requesting and installing an e-mail cert easier. Not that much easier since both have you install something (a program/app or a cert). You’ll have to configure your e-mail client to digitally sign your e-mails to send out invites by adding your public key to those outbound e-mails. That’s a simple config setting. Yet going to Comodo to request a cert, installing the cert, and configuring the client to digitally sign e-mails (and later choosing to encrypt) just seems beyond the expertise of the common e-mail user. However, if they can install Passlok and figure out how to use that then they are very close to what they would could do using S/MIME.
S/MIME and encrypting/decrypting e-mails at the client end (regardless of what e-mail provider you use) has been around for well over a decade. That users are offered these other methods just shows how unwilling users are to learn the features already present in their own e-mail clients. Of course, no webmail client supports S/MIME (you won’t find any encrypt/decrypt features) and more users are switching to webmail clients. So that’s where something like Passlok will help (although the copying and pasting interrupts what could be a more smooth process, like adding controls to the webmail client that when activated for encryption would show the user a new window to enter text and add attachments that the control then encrypts and pastes into the actual webmail’s input control).
For those still using local e-mail clients, especially to avoid the noise of ads in webmail clients or how slow are many webmail clients, S/MIME still works and encryption/decryption is performed entirely at the client end. Alas, not even HMOs or hospitals know how to use S/MIME plus they cannot rely that their customers have S/MIME-capable clients or their patients know how to configure those clients, so they make their patients read messages at their web site.
As I keep reading each “secure e-mail” site to see how they do it (and sometimes have to contact them for more detailed info), and even for Passlok, it seems that S/MIME is just as secure, or more, since – as you mention – the encrypt/decrypt are at the client ends. There is the problem that a cert will hang around for awhile but the free ones only last a year and the user can get new free ones whenever they want (and revoke the old ones). It is an invite process, though, and most users want to encrypt without having to first get the other person’s public key. When I read Passlok’s description, looks a look like S/MIME made easier.
You are absolutely correct that a lot of users will be stumped by having to cut and paste, and this is why I made PassLok for Email, an extension based on PassLok which integrates its main functions with the most popular webmail services. It is now available at the Chrome and Firefox web stores for free. Once you have installed the extension (follow a link and click one button), encryption and decryption are as easy as clicking the PassLok icon, which is now placed within the email tab itself.
S/MIME is a serious and worthy attempt, but how many people actually use it? It is too complicated for the majority of mortals, and there is no way to make it easier so long as it remains based on RSA or DH public keys with upwards of 2048 bits, plus attached signatures. Just looking at one of them is enough to discourage anyone. By contrast, PassLok is based on Curve25519 and its public keys are a mere 50 base36 characters long, which users can even dictate allowed. PassLok for Email attaches the sender’s public key to every encrypted message, and so users never have to worry about key exchange.
Hi,
Thanks so much for the article. I’m definitely going to give PassLok a try.
You don’t discuss the issue of metadata at all in your article. On that point I think Protonmail has the big edge. None of the other products shield meta-data from bulk collection. Of course, that’s also true for Protonmail users who send email to non-Protonmail users. But Protonmail is growing quickly, and as it grows the number of users for whom meta-data is fully protected grows. I’m excited about Protonmail’s business product coming out later this year which will handle multiple mailboxes on a custom domain. Activist orgs that sign up for that service can have all emails secured (within Protonmails security limitations as you’ve pointed out) sent inside the organization with the ease of sending a normal email, AND with no metadata exposure.
No system is perfect. But, as Glenn Greenwald has passionately pointed out, we shouldn’t underestimate the importance of meta-data and how our privacy is limited when it is collected. So I think that protection against meta-data collection should be added to your list in my opinion.
@Shai,
You’re right, metadata can leak a lot of information, and is therefore a nightmare for secure email and texting suppliers. Thanks for pointing this out so I can add this criterion in my next edit of this article.
This is one of the reasons why PassLok is more secure than the other apps reviewed in the article, since it merely encrypts data, and does it in a way that is totally under your control and adds nothing that can identify the user, and then you send it by a way that avoids leaking metadata. For instance, use PassLok to encrypt your messages and then post them under a name known only to your friends on a public forum. Use TOR to access it if you are really paranoid.
Protonmail’s encryption, which you seem to like so much, is definitely NOT under your control because it involves a server and you cannot ever see what the server is doing. Even if the code allegedly running on the server is made public, you still don’t know if this is the code actually running. The service could have been hacked, served a court order for your data, or whatnot. You could have zero security and still be led to believe that everything is okay.