An Analysis of the ProtonMail Cryptographic Architecture [pdf]
eprint.iacr.org
eprint.iacr.org
The author makes-up a straw-man threat model which is not based on anything that ProtonMail has published:
> A crucial security assumption, based on ProtonMail's self-professed security goals in its specification documents (2.1), is that the ProtonMail server P is untrusted.
AFAIK, ProtonMail only claims that your email are unencryptable while you don't access the service. Since they have to receive and relay emails to regular SMTP servers and they provide access via IMAP to regular mail programs, obviously their servers at some point will touch your unencrypted email. Therefore, you put a certain amount of trust on them.
So, yes, under the defined straw-man threat model, ProtonMail is not secure. Thank you Captain Obvious!
Obviously that's not possible when receiving mail via SMTP and providing access via IMAP. But that's not clear to non-technical users. I think it's fair to say that putting the above quote on the landing page is misleading.
EDIT: I was wrong on IMAP, which requires users to install a bridge application that handles decryption. That doesn't change anything about SMTP, though.
Afaik on desktop all those involve the use of the ProtonMail Bridge application [0]? At least that was my understanding when I couldn't get my Thunderbird setup to check ProtonMail accounts, it requires the Bridge application.
The paper is weird in that context because the Bridge application is mentioned only once in the whole paper, as a side note: "For simplicity, we group it with smartphone applications."
But from what I understand their whole Outlook client setup wouldn't even work without it, so desktop clients are just as secure as the smartphone applications when they use the Bridge?
[0] https://protonmail.com/support/knowledge-base/imap-smtp-and-...
Why would they be unencryptable when ProtonMail controls the javascript that "encrypts" the message in the first place?
The main point of Kobeissi's analysis is that ProtonMail could, at their whim, serve whatever javascript they want to the client, including javascript that compromises the encryption or hands over the keys to ProtonMail. If they do this, then it's pretty obvious that the message on ProtonMail's servers would be decryptable by them, no?
But if it were open-source, available on F-droid and reproducibly buildable then it could be potentially more secure than a web application. But even then the users either have to audit the source themselves (unlikely), or trust the developers, or trust one or more 3rd party auditors and make sure they run the same code as audited.
For a web application auditing the client code every time you log in is impractical and you can never be sure you run the same code as a third party auditor.
For example, the password brute force argument. That's actually a part of the paper that does not make sense to us. ZKPP provides guarantees related to the handshake between the client and server. It does not mean and never has meant that the server itself could not mount a brute-force attack on the user password. That would be possible from the server with any PAKE, including SRP, which we use. Having the key encrypted with a derivative of the password does not change this, because it was possible already. Slow password hashes throughout make this difficult of course.
He also attacks the encrypt outside feature, but a malicious third party email provider was never part of the threat model for this feature.
Finally, he attacks the fact that we allow weak passwords. Well, not enforcing strong passwords is a design choice, and not a crypto weakness. You can disagree with this choice, but it's going too far to try to dress it up as a crypto flaw.
Quite frequently the difference between what you want to protect against vs real threat landscape is what rules the expert community’s decision.
I feel your pain (I work at company which improves data security of distributed systems in a number of ways, and get into similar disputes all the time), but the fact that you’re mitigating some of the risks really well does not mean that other security properties will not be scrutinized against commonly recognized threat models.
Not too rewarding, yet the whole security engineering is a Sysiphus’ labor fron day 0. Not having enough of in-community pressure (even when sometimes you’re criticized for a wrong cause, which is 50/50 here) would lead to much worse consequences than a few uncomfortable questions asked.
It rephrases and generalizes his points rather than tackling them head-on.
Kobeissi's main point is that ProtonMail could serve up any javascript they want to the client, including javascript that compromises the encryption or which hands over the encryption keys to ProtonMail.
Nowhere in ProtonMail's response is this point ever directly addressed or even acknowledged.
The only way to address this point, with current technology and current standards, is to discontinue the webapp and force everybody to the native apps on desktop and mobile. It is the opinion of almost everybody in the industry that webapps are necessary, and that's why we, WhatsApp, etc, all provide webapps.
So the point is acknowledged (and has always been acknowledged), but the opinion being expressed (remove the webapp) is not something that we agree with.
It sounds like you just admitted you could.
Browser extensions.
But I don't think everybody are making webapps to service data of their E2EE product, isn't it?
The key point is, if the webapp can be compromised by anybody who are in control of the front-end assets, then what's the point of the entire ProtonMail E2EE thing? Especially when you have other solutions like GPG which also is an open protocol?
"It seems Nadim (the author of this paper) took it really badly when we called him out for intentionally spreading fake news this weekend." [1]
That's really low. The beautiful thing about computers is that we can prove each others right or wrong with technical arguments. If ProtonMail thinks Nadim has a personal grudge against them, wouldn't it be beautiful for them to disprove him with another professionally written paper as Nadim did? They can't.
Also, I think Nadim knows more than anyone the dangers of pushing weak products and marketing them as secure. It happened to him with Cryptocat. It's a thing that can harm reputation and also harm users, Nadim went through that and I believe he has good intentions by presenting this paper.
---
[1] https://www.reddit.com/r/ProtonMail/comments/9yqxkh/an_analy...
I am new to these things.
(This is a little off topic but I figured I'd ask.) I took a look at my key (you can see it on my profile) and noticed it is 2048. Is there a reason to go with 2048 as opposed to 4096?
Sincerely,
Regarding end-to-end encryption, back in 1984, Saltzer et al. [1] argued that "functions placed at low levels of a system may be redundant or of little value". So, proper email encryption is best achieved at the client application level. If we had got that right, ProtonMail would probably be irrelevant.
[1] https://web.mit.edu/Saltzer/www/publications/endtoend/endtoe...
I have found the bar to entry is "how many clicks or steps" is the receiver willing to perform. Even the least technical of my friends can decrypt a PGP or 7-zip file I send them, but I have to put something they really want inside it.
For example, from their security details page [1]:
"This means we don't have the technical ability to decrypt your messages, and as a result, we are unable to hand your data over to third parties."
This is not true for the web client, as shown by the paper and because of the inherent nature of web applications and the (incomplete) verification mechanisms we have today.
In the same page, they claim:
"As ProtonMail is outside of US and EU jurisdiction, only a court order from the Cantonal Court of Geneva or the Swiss Federal Supreme Court can compel us to release the extremely limited user information we have."
I'm not a lawyer and I don't care about the details. But they are saying that there is a way for a court to get their information. If that court cannot be used as a proxy for the US or other country I don't know, and normal users can't easily verify that claim. Only a lawyer could. But I admit, it sounds great!
The hardware security section is complete nonsense:
"Our primary datacenter is located under 1000 meters of granite rock in a heavily guarded bunker which can survive a nuclear attack. This provides an extra layer of protection by ensuring your encrypted emails are not easily accessible to any third parties. On a system level, our servers utilize fully encrypted hard disks with multiple password layers so data security is preserved even if our hardware is seized."
The nuclear bunker thing is really awesome, sounds like a lot of fun. But how does this offer extra guarantees to privacy? Does it have any windows? how secure are the doors? Also, the "multiple password layers" is nonsense, what does that even mean? Are you encrypting the same thing multiple times?
The main problem with ProtonMail and services similar to it is that they keep the concept of e-mail as we know it alive, when it should be disappearing.
ProtonMail's native mobile apps can be somewhat secure yes, but at that point, conceptually, they are the same as any other secure messaging app. But instead they are using an inferior protocol than the one being used by Signal, Wire or WhatsApp.
The claim that WhatsApp and Wire both have webapps I think is valid, every messaging service should do a better work warning users about the dangers of desktop/web-based applications. But if this is their only defense, then I think they should really need to worry about their own service and stop diverting attention.
---