Hacker News new | ask | show | jobs
by kpdemetriou 804 days ago
Think of it this way: if your database gets breached, your app won't leak user data if your users aren't all targeted by active attackers. It's not a substitute for transport security.

If active attackers are an important part of your threat model, you do want to assure the integrity of the payload - and you can ship Minibone in things like Tauri (or Electron) apps, like we do at Backbone.
1 comments
tptacek 804 days ago
"If your users aren't targeted by active attackers" is doing a lot of work there, right? Because you can get that same level of security without an "end-to-end encryption library" --- just encrypt rows, and store the keys in localStorage, or (ick) by deriving keys from passwords, the way this seems to. All the cryptography can live on the server, and the keys can be pushed out to the client. Now you need an active attacker in order to mass-exfiltrate the database, which is what you're going for, right?

But again my real point is just that you've misnamed it. This isn't E2EE. The whole reason we have the term "E2EE" is to capture not trusting the server to manage cryptographic secrecy.

link
kpdemetriou 804 days ago
I'm not sure what you mean - Minibone's entire purpose is to allow you to not trust the server with users' plaintext data.

Naturally, you DO need to run Minibone in an environment that's not compromised, but even if you're concerned about TLS (and there can be valid reasons to be concerned depending on your threat model), web apps can and do run in places other than the browser - that can guarantee the integrity of the bundle.

In any case, for most use cases, database compromise is much more likely than active attacks from APTs that can break TLS.

link
tptacek 804 days ago
Right. But you do have to trust the server, unless you factor out active attackers, who can corrupt the JS context and exfiltrate secrets. If you do that, though, you don't need the clientside cryptography anymore; you can use standard, non-cryptographic browser mechanisms to make the client a root of trust for the data, but run all the cryptography serverside. (Apps have been doing this for decades, for what it's worth). Obviously, you have to trust the server when you do this --- but only because of the threat of active attackers!
link
LinuxBender 804 days ago
In my opinion, if someone can break TLS such as getting your private keys then they are likely also in a position to poison your E2EE code.

I use E2EE on IRC but the code is entirely separate from the IRC server. irssi-otr using OTR Off The Record library. Provided the IRC admin does not monitor private messages and kick me off for sending text they can not read, I can have private communication with any of my friends on any IRC server knowing full well that the admin can not read it. No amount of hacks or updates to the IRC server could possibly intercept and decrypt my messages regardless of whom compels the admin to make every effort to do so. This of course makes libotr a juicy target but that's another topic similar to xz but thankfully there are not yet a significant number of people using OTR, yet.

This leaves the only remaining option of "obtaining secrets by large wrench in person" but there are countermeasures for that as well.

link