<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>1) On web delivery of code for e2e encryption.</p>
<p>Every time user opens site anew, server sends her new app. We may
say that every single time there is an installation of an endpoint
app. And if this an installation of a compromised version, we get
ourselves into "Client State Compromise" situation. Yes, client is
not *completely* compromised, but the most relevant section of it
is.</p>
<p>Let's say that "No Client State Compromise" security assumption
is incompatible with web delivery of code from an untrusted
server?</p>
<p><br>
</p>
<p>2) On storing password-related things on server (oracles that
allow offline brute-forcing of a password).</p>
<p>Is it be fair to say that we have a fundamental trade-off here.
When system design allows user to restore her device with the help
of password alone, server must store things that will ultimately
include oracles that allow brute-forcing of the password.</p>
<p>Restore on a clean device is useful, for example when an attorney
needs to pass a border, at which officer may inspect and copy all
devices, demanding all related passwords. Attorney simply passes
through border with a clean device, restoring it where officer has
no legal right to demand password(s).</p>
<p>When system design has no password-related things stored
server-side, user must carry important keys (encrypted with
passwords, yada-yada). User must be vigilant. What advice should
such user be given for border-crossing?<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 2018-11-20 3:45 a.m., Nadim Kobeissi
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAK-38xVVOjg+mCr17jPcGvMi03ftCVnov3O+TAMCsQ_GFhsumg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">Dear esteemed peers and colleagues,
<div><br>
</div>
<div>I have recently written an analysis of ProtonMail's
cryptographic architecture. ProtonMail is the world's
largest encrypted email provider with over five million
users.</div>
<div><br>
</div>
<div>Abstract:</div>
<div>ProtonMail is an online email service that claims to
offer end-to-end encryption such that "even [ProtonMail]
cannot read and decrypt [user] emails." The service, based
in Switzerland, offers email access via webmail and
smartphone applications to over five million users as of
November 2018. In this work, we provide the first
independent analysis of ProtonMail's cryptographic
architecture. We find that for the majority of ProtonMail
users, no end-to-end encryption guarantees have ever been
provided by the ProtonMail service and that the
"Zero-Knowledge Password Proofs" are negated by the
service itself. We also find and document weaknesses in
ProtonMail's "Encrypt-to-Outside" feature. We justify our
findings against well-defined security goals and conclude
with recommendations.</div>
<div><br>
</div>
<div>Paper available on IACR ePrint:</div>
<div><a href="https://eprint.iacr.org/2018/1121"
moz-do-not-send="true">https://eprint.iacr.org/2018/1121</a></div>
<div><br>
</div>
<div>I welcome your readership and your feedback.</div>
<div><br>
</div>
<div>Kind regards,<br clear="all">
<div>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div dir="ltr"><br>
</div>
<div dir="ltr">Nadim<br>
</div>
<div dir="ltr">
<div>Sent from my computer<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Messaging mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Messaging@moderncrypto.org">Messaging@moderncrypto.org</a>
<a class="moz-txt-link-freetext" href="https://moderncrypto.org/mailman/listinfo/messaging">https://moderncrypto.org/mailman/listinfo/messaging</a>
</pre>
</blockquote>
</body>
</html>