sgwilym
commented
2 years ago I feel that these helpers are good for a subset of applications that lend themselves to explicit inclusion of certain identities (e.g. creating a PM where you choose the participants at the beginning). But we'd like users to have the option of rich applications like Letterbox in an encrypted mode too. But using helpers for this would intensely complicate the logic of writing / reading letterbox documents (e.g. list all threads — don't forget to filter out the ones you can't decrypt), and having user-facing impact (e.g. when you start a thread, you have to choose if it's encrypted and who to include).
I don't think this is a happy story for people trying to write applications for Earthstar at either the interface or logic level. It would be great if every application could get encryption 'for free', and I have an idea for how we could do it.
Something we've discussed is adding a private key for special shares. With these special shares, having the public key (+birds.a123) gives you the ability to read the share's data, but you can only write data if you have the private key.
And I was thinking, what if in addition to read-only shares, we have a third kind: completely encrypted workspaces, where the private key is used to encrypt and decrypt the share's data?
In this mode, every write and read from the share requires the share's private key. And in this hypothetical scenario existing layers like lobby / letterbox / twodays just work because the encryption is baked right into StorageAsync, with the same queryDocs / set API as there'd be in an unencrypted workspace.
As it would stand apart from identities, maybe whole-share encryption is something that uses something other than ed25519 for encryption (as I'm only now just learning that ed25519 is only really intended for signature verification).
We use ed25519 keypairs for signing; these can also be used for encryption.
The plan is to add an easy helper function to encrypt/decrypt a string for a list of keypairs, and let apps handle this themselves. Only the document content will be encrypted, not the path or the rest of the metadata (we need the metadata for the syncing algorithm even if the document content is encrypted and can't be read).
We'll probably want to use
private-boxfrom SSB to do the encryption. It relies onchloridethough, so I think we'll have toHere's how private-box is used to make private messages in Cabal: https://github.com/cabal-club/cabal-core/blob/master/lib/crypto.js
There are very old notes about this topic in the old original earthstar repo: