|
|
|
|
|
by bradleyjg
4593 days ago
|
|
From the "For our technical readers" paragraph, it's unclear what cryptography model you are going for. On the one hand you say that the private key (albeit password protected) is sent to the server after it is generated, but on the other you say that only public key and encrypted data are sent to the server. Is the model fundamentally the same as Lavabit's, which was so devastatingly critiqued a few weeks ago by Moxie Marlinspike? [1] Separately, how do you deal with the fundamental weakness of browser based security?[2] You say that the software will be open source, but will there be any mechanism to verify that the served javascript libraries on any particular visit match the sources on github? Will there be any minimization / compilation that would make such verification difficult or impossible to accomplish? [1] http://www.thoughtcrime.org/blog/lavabit-critique/ [2] see e.g. http://www.matasano.com/articles/javascript-cryptography/ |
|
For your second question, all resources for the site, including javascript, are served over SSL. This will prevent about 99% of MITM tampering attacks. While we can't overcome the inherent weakness in SSL, or guarantee against compromise on the server-side, we are working on a browser extension which will check the code you receive from the server against what is in the repository, so you can at least be alerted of any inconsistencies.
And since the website is all open-source, we're going to make it simple to host it yourself, if you want to be extra-sure that it's not compromised.
EDIT: By "website" I'm referring to the frontend, in-browser code