An Analysis of the ProtonMail Cryptographic Architecture [pdf]
eprint.iacr.org
eprint.iacr.org
The key question being debated is whether or not web applications can constitute end to end encryption. Nadim's opinion is that, as he writes, "no webmail-style application could". His viewpoint is that E2EE is not possible with web clients, period, end of discussion. This is a rather extreme position to take as it would also apply to the web versions of Whatsapp or Wire, for instance.
ProtonMail, like Whatsapp and Wire, offers apps on Linux, Windows, MacOS, iOS, and Android. Like Whatsapp and Wire, we also offer a web app. The major opinion Nadim is expressing here is that we should offer all the above, minus the web-app, because in his opinion, you can't do end-to-end encryption in a webapp. Obviously Whatspp and Wire do not share this opinion. Signal coincidentally does share this opinion.
We do understand Nadim's arguments, and agree that web-apps are less secure than say a native iOS app. Where we differ in opinion is that we don't believe the threat model of web-apps is so fundamentally different from an iOS app, that we need to take the step of not offering a web-app at all. When it comes to mobile apps for instance, the situation is really not so different, particularly since automatic updates are the norm and recommended for security.
There are definitely design decisions that we could have taken to make ProtonMail more secure (no passwords, only passphrases, sync keys between devices using QR codes, no web app etc), but this could compromise usability to a large degree, which runs contrary to our goals.
Disagreeing on design decisions however, does not indicate that the cryptography is unsound or improperly implemented, as this paper seems to imply. That's why this paper reminds us a bit of the now retracted story in the Guardian about Whatsapp's "security flaw", which was in fact a design decision. It is also a bit disingenuous to claim that ProtonMail doesn't meet it's "self-professed security goals", when we have fundamentally different interpretations of those security goals.
Is this seriously your official response to this paper? Is this an official company account?
What is the official response to this report?
https://eprint.iacr.org/2018/1121.pdf
I'm not a cryptography expert but I am a web developer and even I can figure out that typing my password into a web app reveals my private key to you if you want to steal it.
The author is right in one respect: the online and self- updating nature of the web app makes it impossible for anyone to verify what code you're really running.
Reading this report also makes me question your response to the recent hack/extortion incident. Now, I'm not really convinced about your response.
There's nothing in my PM account that's secret and I don't really care if you were hacked. I use PM to avoid being tracked for advertising. But I do agree with the author of this paper that you shouldn't make these security claims which aren't true.
Thanks in advance for your response.
-- D
This is their main defense, they will probably post a link to their GitHub page where the code of the front end application is hosted.
The thing is, to validate that the code published in GitHub is the same one that you're running right now while you're logged into ProtonMail, requires a dynamic analysis challenge that is quite not achievable.
So if ProtonMail decides to go rogue, or if an attacker compromises their servers, it would be doable to send all users, or some targeted users, a modified version of the webapp which steals your password, retrieves the decrypted key, etc, etc, etc.