Rich text E2EE with sync

[steida]

If I understand it correctly, it's chicken-egg problem. We can't put encrypted text to Automerge, and we can't encrypt whole Automerge doc because then we can't do an incremental sync.

What is the current approach to E2EE CRDT? Thank you.

[steida]

And a related question, Because modern cryptography uses byte arrays instead of strings, it would be useful if Automerge could store byte arrays directly.

[pvh]

Like git, the sync protocol requires understanding the structure of the document, but relay and storage servers don't need to have access to the data. If you want end-to-end encryption, ensure all messages sent over the wire are encrypted and decrypt them on the recieving client.

Also, it's not clear to me why you think you can't store encrypted text in Automerge. Automerge is pretty agnostic about what you keep in it. If your text is encrypted you'll need to store it as a blob value -- you can't insert into the middle of an encypted string -- but I've certainly done this.

Last, I note in your title that you want to sync "rich text". Automerge doesn't currently support rich text natively. Our recent Peritext research prototype explored how to do so, but it has not yet been shipped in production. I don't have an ETA for that, but it's something we'd like to do.

[steida]

it's not clear to me why you think you can't store encrypted text in Automerge

By text (rich text) I mean Automerge.Text CRDT type.

doc.text.insertAt(0, here can not be encrypted text)

[pvh]

It wouldn't really be meaningful to insert pre-encrypted text into an Automerge.Text field. The value of using the Text type is that it can merge insertions and so on, if you have encrypted the text already this is not useful. Inserting other text in the middle of a range or modifying bits would break the cypher.

I'd suggest Automerge's relationship to encryption is similar to other data structures (though I realize Automerge is uncommonly featureful). If you'd like to encrypt an Automerge document, encrypt it when you save it or do incremental synchronization over an encrypted channel.

This is what we did in the backchannel paper. All data is transferred via an untrusted mailbox & relay server which has no knowledge of who is using it or what they're sharing.

[steida]

That's what I wrote "here can NOT be encrypted text"

[steida]

encrypt it when you save it

I wrote we can't encrypt it without sacrificing incremental syncing because I was curious whether I am not missed something.

incremental synchronization over an encrypted channel.

What does it mean "encrypted channel"? How we can do incremental synchronization E2EE? That's was my question.

[pvh]

The best method will depend on your use-case, but to sketch a simple solution:

• have both peers connect to a shared relay server end-point
• generate a keypair for each peer
• exchange pubkeys via the relay server
• encrypt all messages to the other peer with that pubkey before sending

The result is that all messages on the wire will be encrypted end-to-end and the relay server doesn't have to know anything except which peer to pass the messages off to.