
Cryptpad: Zero Knowledge, Collaborative Real Time Editing - zerognowl
https://beta.cryptpad.fr/
======
Ar-Curunir
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".

~~~
infodroid
> Why do people insist on using the term zero knowledge for simple
> semantically secure encryption?

Note that in the domain of privacy-enhancing technologies the term "zero-
knowledge" does not refer to "semantically secure encryption". Instead it is
used to mean that a service provider does not have access to user data, and
that this claim can be proven cryptographically. The use of the term zero-
knowledge to promote privacy-respecting services dates back to at least 1997
with the founding of the Canadian company Zero-Knowledge Systems [1], which
provided anonymous communication services [2].

[1]
[https://en.wikipedia.org/wiki/Zero_Knowledge_Systems](https://en.wikipedia.org/wiki/Zero_Knowledge_Systems)
[2]
[http://edition.cnn.com/TECH/computing/9902/11/browsanon.idg/](http://edition.cnn.com/TECH/computing/9902/11/browsanon.idg/)

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

~~~
infodroid
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 services because zero-knowledge
proofs have come a long way and there are now services like Zerocash that
actually make use of them. So using the term to promote a different privacy-
respecting feature may be confusing or misleading.

~~~
SilasX
I wish they would pick a clearer term that's not already in use, like (as I
think they mean in this case) "provider-obscured". Heck, even "homomorphic"
would be better, as that signifies "does stuff you want with your data,
without knowing the content of said data".

------
williamstein
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-
webap...](https://github.com/sagemathinc/smc/blob/master/src/smc-
webapp/misc_page.coffee)

DISCLAIMER: I've spent way too much time on synchronized CodeMirror editing...

------
f47h3r
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...](https://www.ssllabs.com/ssltest/analyze.html?d=beta.cryptpad.fr)

I like the idea though! :)

------
teraflop
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/p...](http://www.cs.utexas.edu/users/lorenzo/corsi/cs380d/papers/p172-terry.pdf)

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

~~~
ar0
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
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.

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

~~~
socrates1024
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
I would very much like to see someone built out the transcript validation
application of atomic broadcast rather than a distributed ledger version.

------
no_protocol
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?

~~~
habitue
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
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.

~~~
habitue
I agree 100%. This means both processes are insecure, though probably it's a
matter of degrees, since you at least have the apple approval process
filtering out blatant fuckery

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

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

~~~
no_protocol
Or a hijacked GitHub repository/maintainer?

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

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

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

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

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

------
t0mbstone
Ok, now this is cool.

------
mempko
why not just make it p2p via webrtc ?

------
mxuribe
Seems cool.

