Protonmail security review

Filed under Security

Note: Protonmail is still in beta, so things might change

Protonmail promises to deliver security to the mail world, accessible without any kind of monitoring from their side. As I write, their project on indiegogo.com has 27 days to go and already reached 128% of the goal.
So, after all the media coverage received by Protonmail, is it really going to be the next alternative to gmail?
But most importantly, is it as secure as it is advertised?
Let’s look into some of its features…

MailPage

 

The interface is very simple, no fuss. Gladly, no advertising so far based on “anonymous data” collected from our mail context. That is a good start I think.
As promised, the javascript side is not compressed, leaving a bit of transparency to the user, but I’ll get to it in a bit…

CodeJS
The interface to compose mails is also very simple; would be comparable to any standard webmail client, if it wasn’t for the encryption features on the right:

SendMail
We can encrypt the mail and give it an expiration. I am not quite sure why would an email expire when saving the contents for offline reading would be very easy, but let’s move on…

Debugging a little bit, seems clear that we use our public key client side to encrypt our mail:

So, the base encryption is AES256.

I believe arguments are then built within #totalpackage and sent (where the pgp part is added for *@protonmail.ch emails):

Then the draft is created:

This is good news – they are using the openpgp.js library to encrypt the messages, so it really happens all on the client side. Ok, but actually, this can be done using thunderbird too or most mail clients. That said, having it javascript based will give me the opportunity to have my pgp data always with me, even on someone else’s device.

Anyway, I clicked in the beginning to send the document encrypted externally. It seems to me that this part:

is responsible for encrypting outbound messages. It looks to me this will encrypt only the message with an hashed AES256 pass (see encryptMessage function in the code above). Keep this in mind, we will get into it in a bit.

We then receive the email from protonmail. Obviously no receiver PK is checked since we don’t know it (and I can’t find a way to add them)

mail

The question at this point is…

Are external mails kept just encrypted using a sha256 of our password using AES256?
It might seem like an OK solution now, but I bet in 5 years time hacking a sha256 won’t take so long. Even now with supercomputers won’t take long to break this SHA256. I personally don’t think at this stage protonmail offers an adequately secure external email.

In addition to that, answering to external emails now is impossible, but this might change.

Now, let’s forget about the AES256 scenario for a while. What are the other issues?
Well, there are no signature and no certificate authorities here, so anybody with access to the mail and the password (let’s assume someone is sniffing chats + mails) can actually get the data.
Ultimately, not using public keys, will lead to an additional exchange of keys, which in turn leads to a less secure solution.

All in all, this is a well thought system, though I think little privacy is offered with externally encrypted emails (which – in theory – can be decrypted by the server owners), and even our local emails might not stand the test of times (also, how scalable is it? Will we be able in the future to change algorithms without rebuilding the whole inbox?)

Never the less, my support goes to the guys, it is a great step forward to what we had before and even though there is room for improvement (and well, it is always possible my analysis has some flaws so welcome to comment) this I think is one way to make cryptography really accessible to anyone.

…Just one last heads-up. There are some pretty heavy limitations (in particular if you are used to Gmail space):
Screenshot - 21.06.2014 - 02:10:25

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*


six − 4 =