Cryptpad: a free/open, end-to-end encrypted, zero-knowledge shared text editor

Tools like Etherpad and Google Docs are transformative ways to collaborate on text (including code); I've used them in contexts as varied as making unofficial transcripts of statements at UN agencies to liveblogging conference presentations -- but they all share a weakness, which is that whomever owns the document server can see everything you're typing.

Cryptpad is a free/open project that uses some of the ideas behind blockchain to implement a "zero-knowledge" version of a collaborative document editor, ensuring that only the people working on a document can see it. The crypto keys are stored in a "fragment identifier" in the URL, so sharing the URL is the same as sharing permission to read and edit the doc. It's on Github, and licensed GPL V3.

CryptPad uses a variant of the Operational transformation algorithm which is able to find distributed consensus using a Nakamoto Blockchain, a construct popularized by Bitcoin. This way the algorithm can avoid the need for a central server to resolve Operational Transform Edit Conflicts and without the need for resolving conflicts, the server can be kept unaware of the content which is being edited on the pad.

Cryptpad

Cryptpad [Github]

(via 4 Short Links)

Notable Replies

  1. What a strange world where security by obscurity is a known fail but security by url obscurity makes some sense.

  2. The secret encryption key is stored in the URL fragment identifier which is never sent to the server but is available to javascript so by sharing the URL, you give authorization to others who want to participate.

    As long as the communication channel used to share the URL is safe and the browser is well behaving, the document is safe. No obscurity here.

  3. But it makes man in the middle attacks trivial. And it is normal to proxy http.

  4. Just like anything HTTP-based, no less, no more. In order to capture to fragment identifier, the attacker must serve a page with a script that will retrieve it and sent it somewhere.

  5. Presumably, you'd set this up over HTTPS, which would protect the URL itself, and use an encrypted channel to communicate the URL (and fragment identifier). I think my preferred way would be gpg-encrypted email (or even just a gpg encrypted attachment) to collaborators containing the URL to use, and go from there.

Continue the discussion bbs.boingboing.net

2 more replies

Participants