<div dir="ltr"><div>Crypto is hard. I hope you have folks reviewing your implementation, especially if you're designing a cryptosystem to protect me from the big bad agencies!</div><div><br></div><div>One thing I see missing from both your product/library github page/indiegogo kickstarter page is a well-defined threat model. You mention your use case and implementation (and I understand it), but I'm curious about what boundaries/assumptions/etc. you had in mind when you built the system? </div><div><br></div><div>-pc<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 17, 2015 at 3:58 PM, Edward Ned Harvey (bblisa4) <span dir="ltr"><<a href="mailto:bblisa4@nedharvey.com" target="_blank">bblisa4@nedharvey.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-US" link="#0563C1" vlink="#954F72">
<div>
<p class="MsoNormal">The present standard practice is for clients/users to establish an HTTPS connection and then send username and password over the wire, where the server will encrypt it using a rate-limiting function such as pbkdf2, bcrypt, or scrypt, to
 protect it against hackers or bad employees who have access to the password file or database or whatever. But wait! We should assume, that hackers and bad employees who can access the password file can also access the encryption programs (drupal, wordpress,
 apache, etc that run bcrypt etc) and have access to the password in-memory before it's encrypted.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Worse yet, even if the server is never breached and the employees are always perfect, users sacrifice their legal right to privacy by merely making it possible for the employees to see it.
<a href="https://en.wikipedia.org/wiki/Third-party_doctrine" target="_blank">https://en.wikipedia.org/wiki/Third-party_doctrine</a> This is like a person writing their password on a postcard and assuming the mail carriers will never bother to look at it. Why do we make a distinction
 between the employees operating the routers on the internet, and the employees operating the web servers at google and facebook and everywhere else? We know we should never login to an http:// site because the random unknown employees who operate internet
 routers could see the credentials in-flight. We've all been trained to only login on valid https:// sites, even though potentially thousands of random unknown employees might be at work on the other end, able to see the credentials in-flight.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">tl;dr<u></u><u></u></p>
<p class="MsoNormal">There is no good reason to do the encryption on the server. It should be ok to reuse passwords on different sites, as long as the passwords are never exposed to the servers.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I work at Concept Blossom, and we're promoting awareness about this issue. We produce
<a href="https://cbcrypt.org" target="_blank">https://cbcrypt.org</a> MIT open-source crypto library to address this issue. We're resource constrained on development, so development is taking place, but slower than we wish. Please spread the word and raise awareness as you
 wish. Even if some other implementation eventually becomes dominant instead of CBCrypt, this is a big important issue that I don't want affecting my daughter when she grows up.<u></u><u></u></p>
</div>
</div>

<br>_______________________________________________<br>
bblisa mailing list<br>
<a href="mailto:bblisa@bblisa.org">bblisa@bblisa.org</a><br>
<a href="http://www.bblisa.org/mailman/listinfo/bblisa" rel="noreferrer" target="_blank">http://www.bblisa.org/mailman/listinfo/bblisa</a><br></blockquote></div><br></div>