8 ms·

Cryptpad: Zero Knowledge, Collaborative Real Time Editing

137 points by zerognowl 10y ago

zmanian 10y ago
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, Tendermint, Honeybadger etc. Great work.
- williamstein 10y ago
  https://roughtime.googlesource.com/roughtime/ https://roughtime.googlesource.com/roughtime/
- socrates1024 10y ago
  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.
  - zmanian 10y ago
    That's disappointing :-(
  - zmanian 10y ago
    I would very much like to see someone built out the transcript validation application of atomic broadcast rather than a distributed ledger version.
t0mbstone 10y ago
Ok, now this is cool.
celticninja 10y ago
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.
- DennisP 10y ago
  Just having encrypted communication doesn't enable collaborative document editing. Seem to me the point is to use a secure channel to share the URL with your collaborators, and after that you can use a blockchain to host your collaborative edits instead of having to run a server.
- ar0 10y ago
  Yes, you need an encrypted (or local) channel to share the Cryptpad URL but this can be achieved by using e.g. PGP or Signal or any other of the encrypted messengers out there. However, being able to send an encrypted message to someone is not the same as being able to collaboratively edit documents in real time (think "Google Docs") with that person. This is where the value-added of Cryptpad lies: Yes, you need to already be able to exchange encrypted messages with your partner, but this will allow you to work on a document together in a secure[1] fashion. For me, this is quite an achievement and not nothing. [1]: "Secure" with all the caveats pointed out in the other comments below, e.g. if you do not self-host but use the cryptpad.fr server you need to trust them not to send malicious JavaScript to your browser.
  - celticninja 10y ago
    I did not mean it was nothing, I was juts seeing if I understood how it works and the risks. But I can see how a collaborative doc would be useful, this would be a good alternative to the shared Gmail account communicate with draft messages option.
no_protocol 10y ago
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?
- anarcat 10y ago
  yes. you can't. and yes.
  - gry 10y ago
    While the ideas and implementation are neat, this suffers from the chicken and egg problem[1]. You have to trust server's resources are not tampered with. Adding an event binding to tamper or siphon data before it's encrypted is simple. [1] https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/ https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...
- habitue 10y ago
  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
  - DenisM 10y ago
    iOS silently installs updates too all apps from the App Store. There is no meaningful distinction between Javascript being served from the server and an App being served from the App Store.
    - teddyh 10y ago
      Yes. Yes they do, and I agree – there is no meaningful distinction. https://www.gnu.org/proprietary/proprietary-back-doors.en.html https://www.gnu.org/proprietary/proprietary-back-doors.en.ht...
Diederich 10y ago
This is pretty cool, but I believe that you still have to trust cryptpad.fr to send you javascript that won't leak.
- no_protocol 10y ago
  From a glance at the GitHub page, it looks like you can self-host the project. Is "bower install" a possible attack vector as well? I'm unfamiliar with it.
  - the_duke 10y ago
    Bower is a package manager for Javascript libraries. So the only attack vector would be a MIT attack, intercepting the requests to the Bower registry.
    - deleted 10y ago
      [deleted]
    - Diederich 10y ago
      Very good, thanks!
    - no_protocol 10y ago
      Or a hijacked GitHub repository/maintainer?
mxuribe 10y ago
Seems cool.
Canada 10y ago
I'd love something similar, but implemented as a browser extension.
throwawayReply 10y ago
Entering an invalid pad number redirects back to old.cryptpad.fr ?
williamstein 10y ago
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 https://github.com/sagemathinc/smc/blob/master/src/smc-webapp/misc_page.coffee https://github.com/sagemathinc/smc/blob/master/src/smc-webap... DISCLAIMER: I've spent way too much time on synchronized CodeMirror editing...
Ar-Curunir 10y ago
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".
- schoen 10y ago
  I think this is a terminological suggestion from SpiderOak https://spideroak.com/features/zero-knowledge https://spideroak.com/features/zero-knowledge It's true that it doesn't match the technical meaning of zero knowledge from cryptography (although maybe arguably the meaning of the technical term could be extended to this situation in a trivial way: rather than a proof or protocol involving Bob from which Bob doesn't learn certain information, this is a protocol not involving Bob from which Bob also doesn't learn certain information).
  - CiPHPerCoder 10y ago
    Counter argument: https://paragonie.com/blog/2016/08/crypto-misnomers-zero-knowledge-considered-self-descriptive https://paragonie.com/blog/2016/08/crypto-misnomers-zero-kno... Summary: zero-knowledge applies to authentication protocols, not encryption protocols.
    - schoen 10y ago
      I think I'm inclined to agree with that interpretation. I wish we had a clearer term for systems where you don't trust an intermediary with some kind of access. (We often say "end-to-end encrypted", but that's kind of weird for file storage or other data-at-rest situations.)
      - CiPHPerCoder 10y ago
        > I wish we had a clearer term for systems where you don't trust an intermediary with some kind of access. We already have one or more of: - Confidential - End-to-end encrypted (contrasted with, but often in addition to, transport-layer encryption) - Privacy-preserving - Least authority (with respect to the service operator) - Peer-to-peer privacy I'm one degree of separation from several SpiderOak engineers and think highly of them overall. However, this choice of marketing copy is one point we vehemently disagree on.
eganist 10y ago
I'm looking forward to tptacek's commentary here given his position on in-browser crypto.
teraflop 10y ago
Interesting idea. 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. 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. [1]: https://github.com/xwiki-contrib/chainpad https://github.com/xwiki-contrib/chainpad [2]: http://www.cs.utexas.edu/users/lorenzo/corsi/cs380d/papers/p172-terry.pdf http://www.cs.utexas.edu/users/lorenzo/corsi/cs380d/papers/p...
mempko 10y ago
why not just make it p2p via webrtc ?
franciscop 10y ago
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: http://secretdiary.org/#IDENTIFIER-AUTOGENPASSWORD http://secretdiary.org/#IDENTIFIER-AUTOGENPASSWORD 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 However it was one of my first projects so it didn't even had https.
lyssa 10y ago
Neat. Using chainpad for the basis of my next project :-)
f47h3r 10y ago
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. You scored an F on SSL Labs. https://www.ssllabs.com/ssltest/analyze.html?d=beta.cryptpad.fr https://www.ssllabs.com/ssltest/analyze.html?d=beta.cryptpad... I like the idea though! :)
beaner 10y ago
Isn't access exposed to whatever medium you use to transmit the URL?

137 points by zerognowl 10y ago

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, Tendermint, Honeybadger etc. Great work.

williamstein 10y ago
https://roughtime.googlesource.com/roughtime/ https://roughtime.googlesource.com/roughtime/
socrates1024 10y ago
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.
- zmanian 10y ago
  That's disappointing :-(
- zmanian 10y ago
  I would very much like to see someone built out the transcript validation application of atomic broadcast rather than a distributed ledger version.

t0mbstone 10y ago

Ok, now this is cool.

celticninja 10y ago

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.

DennisP 10y ago
Just having encrypted communication doesn't enable collaborative document editing. Seem to me the point is to use a secure channel to share the URL with your collaborators, and after that you can use a blockchain to host your collaborative edits instead of having to run a server.
ar0 10y ago
Yes, you need an encrypted (or local) channel to share the Cryptpad URL but this can be achieved by using e.g. PGP or Signal or any other of the encrypted messengers out there. However, being able to send an encrypted message to someone is not the same as being able to collaboratively edit documents in real time (think "Google Docs") with that person. This is where the value-added of Cryptpad lies: Yes, you need to already be able to exchange encrypted messages with your partner, but this will allow you to work on a document together in a secure[1] fashion. For me, this is quite an achievement and not nothing. [1]: "Secure" with all the caveats pointed out in the other comments below, e.g. if you do not self-host but use the cryptpad.fr server you need to trust them not to send malicious JavaScript to your browser.
- celticninja 10y ago
  I did not mean it was nothing, I was juts seeing if I understood how it works and the risks. But I can see how a collaborative doc would be useful, this would be a good alternative to the shared Gmail account communicate with draft messages option.

no_protocol 10y ago

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?

anarcat 10y ago
yes. you can't. and yes.
- gry 10y ago
  While the ideas and implementation are neat, this suffers from the chicken and egg problem[1]. You have to trust server's resources are not tampered with. Adding an event binding to tamper or siphon data before it's encrypted is simple. [1] https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/ https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...
habitue 10y ago
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
- DenisM 10y ago
  iOS silently installs updates too all apps from the App Store. There is no meaningful distinction between Javascript being served from the server and an App being served from the App Store.
  - teddyh 10y ago
    Yes. Yes they do, and I agree – there is no meaningful distinction. https://www.gnu.org/proprietary/proprietary-back-doors.en.html https://www.gnu.org/proprietary/proprietary-back-doors.en.ht...

Diederich 10y ago

This is pretty cool, but I believe that you still have to trust cryptpad.fr to send you javascript that won't leak.

no_protocol 10y ago
From a glance at the GitHub page, it looks like you can self-host the project. Is "bower install" a possible attack vector as well? I'm unfamiliar with it.
- the_duke 10y ago
  Bower is a package manager for Javascript libraries. So the only attack vector would be a MIT attack, intercepting the requests to the Bower registry.
  - deleted 10y ago
    [deleted]
  - Diederich 10y ago
    Very good, thanks!
  - no_protocol 10y ago
    Or a hijacked GitHub repository/maintainer?

mxuribe 10y ago

Seems cool.

Canada 10y ago

I'd love something similar, but implemented as a browser extension.

throwawayReply 10y ago

Entering an invalid pad number redirects back to old.cryptpad.fr ?

williamstein 10y ago

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 https://github.com/sagemathinc/smc/blob/master/src/smc-webapp/misc_page.coffee https://github.com/sagemathinc/smc/blob/master/src/smc-webap... DISCLAIMER: I've spent way too much time on synchronized CodeMirror editing...

Ar-Curunir 10y ago

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".

schoen 10y ago
I think this is a terminological suggestion from SpiderOak https://spideroak.com/features/zero-knowledge https://spideroak.com/features/zero-knowledge It's true that it doesn't match the technical meaning of zero knowledge from cryptography (although maybe arguably the meaning of the technical term could be extended to this situation in a trivial way: rather than a proof or protocol involving Bob from which Bob doesn't learn certain information, this is a protocol not involving Bob from which Bob also doesn't learn certain information).
- CiPHPerCoder 10y ago
  Counter argument: https://paragonie.com/blog/2016/08/crypto-misnomers-zero-knowledge-considered-self-descriptive https://paragonie.com/blog/2016/08/crypto-misnomers-zero-kno... Summary: zero-knowledge applies to authentication protocols, not encryption protocols.
  - schoen 10y ago
    I think I'm inclined to agree with that interpretation. I wish we had a clearer term for systems where you don't trust an intermediary with some kind of access. (We often say "end-to-end encrypted", but that's kind of weird for file storage or other data-at-rest situations.)
    - CiPHPerCoder 10y ago
      > I wish we had a clearer term for systems where you don't trust an intermediary with some kind of access. We already have one or more of: - Confidential - End-to-end encrypted (contrasted with, but often in addition to, transport-layer encryption) - Privacy-preserving - Least authority (with respect to the service operator) - Peer-to-peer privacy I'm one degree of separation from several SpiderOak engineers and think highly of them overall. However, this choice of marketing copy is one point we vehemently disagree on.

eganist 10y ago

I'm looking forward to tptacek's commentary here given his position on in-browser crypto.

teraflop 10y ago

Interesting idea. 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. 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. [1]: https://github.com/xwiki-contrib/chainpad https://github.com/xwiki-contrib/chainpad [2]: http://www.cs.utexas.edu/users/lorenzo/corsi/cs380d/papers/p172-terry.pdf http://www.cs.utexas.edu/users/lorenzo/corsi/cs380d/papers/p...

mempko 10y ago

why not just make it p2p via webrtc ?

franciscop 10y ago

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: http://secretdiary.org/#IDENTIFIER-AUTOGENPASSWORD http://secretdiary.org/#IDENTIFIER-AUTOGENPASSWORD 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 However it was one of my first projects so it didn't even had https.

lyssa 10y ago

Neat. Using chainpad for the basis of my next project :-)

f47h3r 10y ago

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. You scored an F on SSL Labs. https://www.ssllabs.com/ssltest/analyze.html?d=beta.cryptpad.fr https://www.ssllabs.com/ssltest/analyze.html?d=beta.cryptpad... I like the idea though! :)

beaner 10y ago

Isn't access exposed to whatever medium you use to transmit the URL?