[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.