Is email encryption, as claimed by ProtonMail, possible?

Question

Is it possible to create a Web service that encrypts all messages, such that only the writer, and the person to whom the mail is sent, can read it? In other words, is the theory behind ProtonMail valid?

Answer 1

Strictly speaking it is not possible, for the following reason: if the Web service encrypts the message, then the Web service gets to see the unencrypted message at some point (note: I write service, not server). At best, the service may be honest and do its best not to have a look at the messages at they flow.

Now let's see the claims of that "ProtonMail" service:

• Swiss Based. Well, I see no reason to find this implausible. Switzerland is a real country and there are people who live there. However, they suggest that by being a "Swiss service", the data immediately come under the cover of Swiss law, which is a rather bold statement. Electrons don't have a nationality, and, contrary to a piece of paper, an electronic message does not have a well defined geographic position at all times.

• Zero Access to User Data. That one is not completely true. When you write your message, you do it in their Web site. Even if all encryption technically occurs in your browser, that would still be done using the Javascript code that they send to you every time you connect to their service. If they want to read your messages without you noticing it, they can.

• End-to-End Encryption. This is possible, if encryption is Javascript-based on the sender's browser, and decryption is again Javascript-based on the recipient's browser. Taking into account the pitfalls of doing crypto in Javascript.

• Anonymous. I don't believe that one, at least not in the long term. They claim not to log anything; however, experience of past anonymous remailers shows that the logs are the only thing that stands between the remailer operators and jail, in some extreme cases (e.g. if the service is used to coordinate some terrorist actions). Almost invariably, the claim of not logging turns out to be fake after a while. On a similar note, even if the site operators are idealist enough not to log anything, eavesdropping on the network provider side is enough to get a lot of metadata and, e.g., work out who talks to who. This is called traffic analysis. It works well and no Web service can protect against that (only network-wide systems like Tor stand a theoretical chance to defeat traffic analysis).

• Securely communicate with other email providers. That one makes me cringe a bit. They mean that when the recipient is not a ProtonMail registered user, they send a normal email with an embedded link to their site, so that the user may download the encrypted email and the piece of Javascript that decrypts it. As they say it, this requires that you previously shared a password with the recipient by some unspecified mean. The bad part here is that it trains people to click on links received by email, and then enter their passwords on the resulting Web page.

• Self Destructing Messages. This one works just as well as, or as bad as, copy protections on movies. The raw fact is that if the recipient could read the message at some point, then he can get a copy indefinitely (if only by taking a photo of the screen with his smartphone). The "self destruction" is more a declaration of intent (pleeease don't save this email) than a security measure that can be really enforced. (However, automatic destruction of messages after a time will sure help the ProtonMail administrators, since they store the encrypted emails on their systems and don't want to do that indefinitely, because disk space, though cheap, is not free.)

• Open Source Cryptography. That one is believable, and good news. At least they don't reinvent their crypto, but use time-honoured standards (in this case, OpenPGP). (I don't recognize any name in their list of security experts, but I don't know everybody. Effort at transparency is good.)

• Hardware Level Security. They don't mean a HSM; they mean that they lock the doors of their server rooms, and use disk encryption. That last bit is weird: weren't the emails supposed to be already encrypted ? What private data remains, that they feel that it should be encrypted again ? This looks like security theatre to me.

• SSL Secured Connections. This is very plausible, and very much needed in order to avoid third-parties tampering with their Javascript. Not using SSL would be a killing flaw in their system. Unfortunately, they spoil the effect by adding: "To allow extremely security conscious users to further verify that they are in fact connecting to our server, we will also release the SHA3 hash for our SSL public key". Publishing the hash of your public key makes sense only if people can obtain the hash in an untamperable way; if that hash is simply pushed on your own SSL Web site then you are running in circles. Invoking the magic of "SHA3" reveals the extent of the seriousness of that claim: this really is just some more security theatre (not the least since SHA-3 does not exist yet: right now, FIPS 202 is still a draft). (In fact they published the SHA-1 hash, not SHA-3.)

• Easy to Use. For that one, you will have to judge for yourself. "Ease of use" depends on who uses it.

Summary: ProtonMail appears to be roughly the equivalent of using PGP, except that it is Web based, thus centralized. It brings back a lot of issues that PGP was supposed to solve, namely that there is a central server that gets to see who talks to who, and that serves the actual code repeatedly. That central server is thus a juicy target for whoever is intent on spying on people. The decentralized nature of PGP is its biggest asset against attackers; by making it Web-based, they increase the ease of use but abandon that decentralization.

While ProtonMail is certainly better than plain, unencrypted email, it would be wrong to believe it to be the ultimate answer to email security. At least, they made some efforts:

• They use existing standards.
• They have an explicit threat model. Even if it is not very detailed, at least they know the expression "threat model", which puts them in the top 5% of vendors of security systems.
• They try to be transparent.

On a less bright note, I did not see anything related to opensourceness. That is, they say that they use "open source libraries" for cryptography, but they don't actually say which libraries these are; and they don't show their own source code, either. Users are back to having a look at the Javascript code and do their own reverse-engineering, and that does not look very opensource to me.

They also don't actually given any details on their protocol. Since they don't know (or so they say) the "mailbox password" of the recipient, then this begs the question of how they can push an email into that mailbox. We can infer that the mailbox includes a public/private key pair, and the mailbox password is really used to encrypt the private key, not the mailbox itself; this is what would make sense with the information they give (in particular reliance on OpenPGP). But it would be better if they said it. If the protocol is fine then it should be published; there is no reason not to do so. No source and no protocol are very bad points and they really should fix that.

Summary of the summary: ProtonMail's security can be summed up as: their system is secure because they say that they are good guys, honest and all, and they claim to be competent. So that's all fine, eh ?

Answer 2

Yes. ProtonMail uses client side encryption.Your browser encrypts the message. You are limited to your browser's weakness but yes, it is as they claim. End to end with no knowledge of your message.

Answer 3

Proton mail to non-Proton mail looks to be extremely vulnerable to a MITM attack where the user is directed to a phony web page which gets their secret shared password (there must be one otherwise there's no security at all) and then decodes the mail elsewhere using that password and sends the decoded results to the user in a style that looks like the real page.

Answer 4

Yes there is a secure password / code to access the encrypted emails. If I know the recipient well they know the following drill. For recipients I haven't communicated with before I send the email they need to contact me for the password at which point I instruct the recipient to enter an incorrect password first to ensure legitimacy, if it goes through unchecked then it is potentially a MITM attack. Also if this is a one-off to someone don't usually deal with but have communicated with beforehand I will send an incorrect password to recipients first (say by and encrypted text service) to ensure they text me back for the correct one. Perfect, no, a determined hacker may figure it out eventually, but better than nothing.