
An Analysis of the ProtonMail Cryptographic Architecture [pdf] - phoe-krk
https://eprint.iacr.org/2018/1121.pdf
======
m000
I've quickly skimmed through the paper and the ProtonMail whitepaper the
author supposedly based their analysis on. Sorry to be harsh, but the
_conclusions_ of the analysis are pretty much BS. The reason is that the
threat model defined by the author is obviously not the one ProtonMail defends
against.

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!

~~~
lorenzhs
Unless you count the promises on their front page. " _All emails are secured
automatically with end-to-end encryption. This means even we cannot decrypt
and read your emails. As a result, your encrypted emails cannot be shared with
third parties._ "

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.

~~~
freeflight
> Obviously that's not possible when receiving mail via SMTP and providing
> access via IMAP.

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-...](https://protonmail.com/support/knowledge-base/imap-smtp-and-
pop3-setup/)

~~~
lorenzhs
Oh, looks like you're right on IMAP. But they still receive mail via SMTP from
other servers, there's no way around it if you want to be able to receive
email from people not using your service. You need to be confident that their
receiving servers encrypt your email without storing an unencrypted copy
elsewhere.

------
ninegunpi
There are good general observations on e2e claims for any web app (5.1 and
part of conclusions section), which apply to almost any web app, aside from
design flaws in the protonmail itself.

~~~
protonmail
These "design flaws" are more like design choices, which this paper
misrepresents as flaws.

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.

~~~
ninegunpi
I do get your arguments very well: having to advocate ZKPP primitive in our
own solution I end in discussions about ‘ZKPP does not prevent brute force’ a
lot. But it’s unfair to rule out the analysis because this is a choice - these
are weaknesses, they are making the system weaker. The fact that you’re
providing ibcremental security in many spheres of your influence does not mean
that, when being questioned, they are atill weak against practical risks.
‘Secure against chosen threat model’ is OK when threat model reflects reality,
paper’s author, I think, is coming not from basis of your threat models, but
from basis of security challenges of modern e-mail.

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.

------
r721
ProtonMail's response:
[https://news.ycombinator.com/item?id=18492982](https://news.ycombinator.com/item?id=18492982)

~~~
pmoriarty
This response does not directly address Kobeissi's points.

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.

~~~
protonmail
This point has been acknowledged since day one though, and it is not a point
specific to ProtonMail. Any E2EE service that has a webapp is susceptible to
this, and that's essentially all E2EE services out there.

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.

~~~
rqs
> Any E2EE service that has a webapp is susceptible to this

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?

~~~
protonmail
ProtonMail is based on GPG actually, and we also have native desktop and
mobile apps. The webapp is just one platform that we support, out of many.
E2EE services providing webapps is actually not uncommon, e.g. WhatsApp, Wire,
etc.

------
moonsun
Hi,

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,

------
MrXOR
The End-to-End-Encrypted Web is a myth!

~~~
m000
End-to-End-* is typically just a buzzword. Interpretation is different,
depending on who you ask and what is the subject.

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...](https://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf)

------
trash_panda
The analysis by Kobeissi is correct, and the claims by ProtonMail are a
stretch, and sometimes they don't mean anything.

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.

\---

[1] [https://protonmail.com/security-details](https://protonmail.com/security-
details)

