Cryptpad: Zero Knowledge, Collaborative Real Time Editing

Post by DenisM » Fri, Sep 23, 2016, 9:26 PM UTC

habitue wrote: post #30

no_protocol wrote: post #5

I have often seen claims that doing any kind of crypto in (browser) javascript is dangerous. Does this fall into that trap? How can I safely share the URL to someone without already using an established encrypted communication method? Is the encryption key stored in my browser history?

The reason crypto in the browser is dangerous is because the crypto algorithms come from the server (they aren't built into the browser) so you have to verify them every time you go to the site to know they're doing everything properly. They could easily change them to no ops for you at the request of the NSA or whatever and you wouldn't know. So on the basis of that, I don't think this project avoids that problem

Post by rarrrrrr » Fri, Sep 23, 2016, 10:40 PM UTC

Ar-Curunir wrote: post #17

Why do people insist on using the term zero knowledge for simple semantically secure encryption? Zero knowledge has a very specific meaning inside cryptography. Encrypting something does not make it "zero knowledge".

Post by dogma1138 » Fri, Sep 23, 2016, 10:43 PM UTC

infodroid wrote: post #39

Ar-Curunir wrote: post #37

Earlier quoted context omitted.

Note that in the field of cryptography, the term zero knowledge refers to zero knowledge proofs, which predate that company by over 13 years.

I don't dispute that fact. But there is precedent for the use of the term in privacy-respecting services, so we shouldn't be surprised when we encounter it. After ZKS shut down, the term continued to be used by hosting and communications services to explain their value proposition in a simple way. Having said that, I agree with the point that nowadays this usage may be unhelpful in promoting privacy-respecting servic…

Post by socrates1024 » Fri, Sep 23, 2016, 11:14 PM UTC

zmanian wrote: post #2

This is a cool implementation of this idea. Proof of work is probably an acceptable solution for proof of concept but anonymous consensus isn't needed for for collaborative document editing. 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,…

Post by zmanian » Fri, Sep 23, 2016, 11:42 PM UTC

socrates1024 wrote: post #47

zmanian wrote: post #2

This is a cool implementation of this idea. Proof of work is probably an acceptable solution for proof of concept but anonymous consensus isn't needed for for collaborative document editing. 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,…

There doesn't appear to be any mining, proof-of-work, anonymous consensus, or fault-tolerant consensus of any kind in this project. I think they just threw the phrase "Nakamoto blockchain" in there as inspiration, really they are just using hashchains from 1999.