← Back to context

Comment by jchw

2 years ago

I saw this recently and I am really excited for, hopefully, a renaissance in local-first apps; it's been quite a long time coming. That said, it seems like there's still a lot of problems to work on in this space and it'll take a while for different approaches and implementations to approach their local maxima.

I am curious about encryption. Assuming that ElectricSQL is handling essentially all of the syncing, is it possible to build applications that use end-to-end encryption for some of their state? I am wondering specifically because CRDTs seem to simplify E2EE a lot since well, any client that can write can resolve conflicts any time. I haven't looked very deeply yet as I've been very busy, but to me that's the main thing I've been really curious about. I know you can at least do this with Y.js which helpfully provides a way to use symmetric encryption for WebRTC synchronization, but this obviously is a whole lot more than that.

9 comments

jchw

Reply
samwillis  2 years ago

Absolutely, we are really keen to support an encryption pattern. We are at the design phase, the current thinking is to have a hook enabling developers to provided their own encryption callback so that you can have unencrypted data in the local database. Essentially encrypting and decrypting, on and off the sync layer.

klabb3  2 years ago

You can always encrypt local data even if the metadata is not encrypted. But that restricts it to the device itself by default, not even your other devices on the same account can read it.

If you want encrypted and shared with other devices or users you have to surface key management to users which is very difficult to do. Signal and a few others do this but they’re very bespoke to the specific business logic. To provide a general purpose abstraction layer is still an open problem, afaik.

  • jchw  2 years ago

    I'm not asking for the problem of key derivation to be solved by ElectricSQL per se, just wondering if it can handle E2E encrypted data in any way. That said, I disagree with how difficult it is: there are a lot of approaches that are not too ridiculous. For example, a simple approach to E2EE is to use a PAKE like SRP to do password authentication, then since the password is kept secret, you can use a normal KDF to derive a symmetric key from the password. From here, you can e.g. store symmetric and public key matter on a server or synced across your clients, encrypted using the password/KDF. If this sounds familiar, it's exactly how password managers work and the main downsides are that it requires password authentication (can't use any auth mechanism that doesn't somehow discretely convey a secret to the client) and the forgot password situation is more complicated (if you have no backups of the key, you can't recover any data. However, that's not an unreasonable compromise in exchange for E2EE.)

    Just like TLS, it'd probably be bad if most people implemented SRP from scratch. That said, I did write my own implementation of SRP-6a (a variant of SRP based on the RSA cryptosystem) in TypeScript and I found it fairly simple to do. There are also PAKEs that provide even better security properties than SRP-6a, but good implementations of them are still lacking for now.

    What Matrix does seems pretty simple, it just has a lot of moving parts and nuance; the underlying keys are essentially sent directly between clients after a key exchange is performed and verified out of band to ensure there is no eavesdropping and that the two clients are connected to who they think they are.

    As far as I know, Signal sidesteps key management almost entirely and only allows one logged in device, and everything else must proxy through it. That's pretty lame, though I understand the stakes are very high to get it 'right' and keeping the moving parts to a minimum was likely high priority.

    • klabb3  2 years ago

      I don’t disagree with your technical assessment per se but I would would not label any of this “pretty simple”, except for special purpose apps with technically competent users.

      Academically it’s in a decent state, but tech- and UX wise I’d say it’s immature. It virtually penetrates all layers of a normal stack (including layer 8). For apps it’s at least possible but the web is very tricky as a platform for anything e2ee without absurd usage requirements.

      The tech choices that remain after deciding on an e2ee model are severely limited and language dependent, and spans deeply across persistence layers, software updates, authn, authz, social graphs, moderation etc etc. And even so, there are many subtleties in terms of privacy and information leakage that are often necessary compromises for features that many apps take for granted today. Without any social aspects it’s significantly easier (eg PAKE is best suited for for interactive/online two-party operations).

      2 replies →

vmfunction  2 years ago

Thank you for saying this. I can see this will help app developers to make more apps that can work in airplane mode. More and more we need apps like that. Why do we need internet for an app to work locally on my computer. The whole google, meta, apps are just annoying to require the user to be online to work.