Why do people insist on using the term zero knowledge for simple semantically secure encryption?<p>Zero knowledge has a very specific meaning inside cryptography. Encrypting something does not make it "zero knowledge".
I know this is just a proof of concept demo, but the "Code Pad" mode is built on CodeMirror and becomes unusably slow as soon as the document gets at all large (few thousand lines) perhaps due to them not implemented a range of tricks for transforming CodeMirror's content efficiently, like the setValueNoJump extension here <a href="https://github.com/sagemathinc/smc/blob/master/src/smc-webapp/misc_page.coffee" rel="nofollow">https://github.com/sagemathinc/smc/blob/master/src/smc-webap...</a><p>DISCLAIMER: I've spent way too much time on synchronized CodeMirror editing...
Seeing as how the key is only being protected by TLS in the GET requests. You may want to tighten up your configuration. Also, patch the padding oracle vuln.<p>You scored an F on SSL Labs.<p><a href="https://www.ssllabs.com/ssltest/analyze.html?d=beta.cryptpad.fr" rel="nofollow">https://www.ssllabs.com/ssltest/analyze.html?d=beta.cryptpad...</a><p>I like the idea though! :)
Interesting idea.<p>I think it's kind of odd to draw such a strong comparison to the Bitcoin blockchain. As the technical description [1] points out, the "chainpad" system discards most of the features and properties that make Bitcoin secure against malicious participants. That seems like a totally reasonable design decision for this application, but then describing it as a blockchain just adds confusion.<p>In fact, the design seems to bear a much closer resemblance to the Bayou optimistic concurrency algorithm [2], with operational transformation as the underlying data model, and some extra crypto on top.<p>[1]: <a href="https://github.com/xwiki-contrib/chainpad" rel="nofollow">https://github.com/xwiki-contrib/chainpad</a><p>[2]: <a href="http://www.cs.utexas.edu/users/lorenzo/corsi/cs380d/papers/p172-terry.pdf" rel="nofollow">http://www.cs.utexas.edu/users/lorenzo/corsi/cs380d/papers/p...</a>
Sharing the URL is essentially giving out the key, so there is no digitally safe way to do this unless you encrypt the initial message, at which stage you are using encrypted communication anyway and the URL just leaves open an attack vector. Please correct me if I am wrong.
This is a cool implementation of this idea.<p>Proof of work is probably an acceptable solution for proof of concept but anonymous consensus isn't needed for for collaborative document editing.<p>I'm still thinking if this use cases needs timestamping or atomic broadcast.If timestamping is sufficient, Google's new roughtime protocol would do the job well. Otherwise you need a proper atomic broadcast algorithim like RAFT, Tendermint, Honeybadger etc.<p>Great work.
I have often seen claims that doing any kind of crypto in (browser) javascript is dangerous. Does this fall into that trap?<p>How can I safely share the URL to someone without already using an established encrypted communication method?<p>Is the encryption key stored in my browser history?
I did something like this 3-4 years ago, it was in secretdiary.com (or .org), now with different people. The main difference is that the url fragment had two parts:<p><a href="http://secretdiary.org/#IDENTIFIER-AUTOGENPASSWORD" rel="nofollow">http://secretdiary.org/#IDENTIFIER-AUTOGENPASSWORD</a><p>The autogenerated password was optional (and random) and you could instead require a password. This way it was not GET-cached anywhere unless you wanted it to so you could share the actual URL anywhere with no fear of it leaking the secrets, or you could just share the whole thing similarly to cryptpad.fr<p>However it was one of my first projects so it didn't even had https.