[tptacek]

I didn't ask an abstract question. I'm asking specifically: what can you accomplish with designs like this that you can't accomplish with TLS and serverside encryption? When you think about that, work out what the threat model is. Yes: with serverside encryption, the server briefly sees plaintext, or can record keys. But with clientside Javascript encryption, the server can exfiltrate keys and recover the same data. The question is specific: what's the advantage, in what threat model?

[kisamoto]

Okay we can go through a threat model. We have a user, a service and an attacker.

Scenario 1: Attacker external to service

With TLS and server side encryption (generally at rest), if an attacker breaches the service they will have full access to all user data. The server has the encryption/decryption keys.

With client side encryption, if an attacker breaches the service they have access to many encrypted blobs that they need to decrypt. If the attacker wants to do this they have to create and plublish a malicious JS and update any resource integrity before waiting for the users to use the malicious version and even then will only get a subset of user keys.

Scenario 2: Attacker internal to service

With TLS and server side encryption, a malicious employee can generally get access to the unencrypted data. Once again, the server will have a copy of the key. Whether by accident or on purpose, plain text user data can be leaked into logs, dumped into backups etc.

With client side encryption, the attacker only has access to ciphertext. Again, they would need to publish a malicious library, bypass any resource integrity at the same time and wait - remaining undetected - for every user to log in so their keys could be siphoned away.

-----

It may be the case that the server needs access to plain text data in which case a more complex approach using a unique user key pair where the public key encrypts the data after processing so the server cannot decrypt it could be utilized. But even then, there will still need to be some JS sent to browser for that logic.

If there is no business reason for the server to see the plaintext data, client side encryption should be preferred.

[tptacek]

No. In scenario 1, with TLS, an attacker gets access only to data corresponding to incoming requests. The same thing clientside Javascript cryptography code does to push secrets out to the client (either by deriving keys from memorable secrets or using local storage) works to store secrets serverside encryption can use; lots of encrypted cookie systems have been built to do this.

Your scenario 2 analysis works by suggesting that attackers can't easily subvert the Javascript contexts of clients (it mentions for instance "resource integrity"). But every request for any resource that alters the DOM or loads code allows an attacker to pull this off; it's the premise of the attack. This is an even weaker case for browser JS crypto.

I think the big premise mismatch we have is that you're assuming I'm saying "just use TLS and store keys on the serverside".

I feel like discussions about WebCrypto always fall apart in arguments over abstractions, like software update versus HTTP requests. But I'm saying, it seems like you can literally just skip all the clientside cryptography, stuff keys in cookies (or whatever), and do all the encryption serverside, and end up with the same threat model, which to me is telling.

I don't think people are crazy for pushing back on this. People smarter than me disagree about it. I wonder if David Adrian wants to take a swipe at this argument.

[kisamoto]

Ah - you might be right that there are some crossed wires here as I was imagining a "just use TLS and store keys on the server" scenario.

Could you correct me please so we're on the same discussion ground? Where does encryption happen and what mechanisms are used to ensure the security of keys?

[tptacek]

I don't know. Just do what this library does: encrypt rows with AES-GCM. Use random keys, push the keys to clients in cookies or to store in local storage. The server "sees" the key when incoming requests arrive, but doesn't store them.

[kisamoto]

Thanks.

Hm I still would prefer plain text not leaving the device. There have been historical examples of plain text passwords ending up in logs (Twitter) so I would prefer encrypted on my device so there's no chance of interception (mistaken or purposeful) on the server.

Plus this would result in a loss of features - keys would then live only on a device for as long as the cookies/storage existed. New browser/device/clean storage the keys are lost and the ciphertext unable to be decrypted.

[btown]

It may be easier for an insider or compromised server to add a silent exfiltration functionality to server code, than to additionally compromise the frontend build, add a side channel by which the client could transmit the secret to the server or to a third party, and exfiltrate the data itself, all without detection. Defense in depth!

Oh, and a deactivated account, where no client with secret access ever gets updated or executes code again, will never leak its secrets, regardless of level of (pre-quantum) compromise of the company. Useful for limited-time communications that need to be private from sophisticated adversaries in perpetuity.

Not to mention that it signals commitment of your company to data privacy, which may deliver value in and of itself.

[tptacek]

I don't understand the first point as a claimed security level with a specific threat model. The second point, about deactivated points, is equally true of serverside encryption --- again, assume keys stored clientside, but encryption code run serverside (in fact, it can be true in applications that don't encrypt at all).

[btown]

If I have a 0day for your backend stack, or you fail to upgrade a dependency, I might get RCE on your backend server and install an exfiltration system, but I would not necessarily be able to pivot to changing the frontend bundle on the static CDN without compromising the CI/CD and code review system, which (hopefully) uses isolated credentials and has strong audit logs. A threat model where even a persistent or long-running infection on backend servers allows user content (if not metadata) to remain opaque can be useful.

[Aachen]

Server compromise is one of the threats this help manage. In your "just TLS to the server" scenario, that means all data is now instantly readable to the attacker. When all data is encrypted with keys only known to the client, the attacker first needs to take active measures and wait for everyone to log in, which may be visible to attentive clients (think reproducible builds, or the same way that someone might reverse engineer WhatsApp to see if they really did implement the Signal protocol correctly)

I've also been the victim of an attack where passive interception was feasible but not active interference. Everything they could use my session token for, they did, but my password was client-side hashed and thus the admin panel (access logs showed attempting to reach it) was safe because it required entering the password again

As a last example, I don't know what binary Signal gives me, but it gives me piece of mind that it requires colluding with Google to target someone specific, so they effectively give everyone the same binary and any backdoors are visible to all at the same time. I really like client-side cryptography as compared to the server being one big black box we just have to trust

[tptacek]

See above; I addressed the same claim in your sibling comment.

[Aachen]

Iff you are referring to https://news.ycombinator.com/item?id=39976605 (providing a link to what you're talking about might have been more fruitful), you've not read most of my reply. They mention only data at rest or an implementation bug whereby the server stores all keys at rest in an accessible format (both a similar scenario), which I now understand you say we can still have with server-side crypto, but they don't mention and you don't seem to reply to the transparency aspect that a lot of my comment is about

[defend]

Disclaimer: I'm a minibone co-author.

A pointed question. Under threat models where you trust (or have verified) the code being executed, this allows you to use untrusted storage (e.g. cloud databases, S3, etc.) without worrying about passive attackers being able to read your data.

Using TLS and server-side encryption, a passive attacker could install a shim to intercept data.

In practice, one usecase of Minibone would be open-source electron-style web applications where you have the necessary code transparency AND signed code versioning. Another would be self-written applications (assuming you trust yourself). Another might be closed-source internal tooling (assuming you trust your company) that's hosted on cloud infrastructure.

If I've overlooked anything, please do let me know.

[tptacek]

I have no trouble at all with libraries like this for Electron apps. In fact, I'd go a step further and say I concede the argument for Chrome Extensions and the like. It's content-controlled code that's problematic here.

[kaoD]

Maybe you trust the server to serve legit JS (or have some other mechanism to ensure it, like content addressing e.g. IPFS) but you don't trust the server not to leak/log your info by mistake if it was processed in the server.

[onethought]

So you both trust and don’t trust the server?

I think the original question is, how is that different to TLS? It seems exactly the same to me.

[kaoD]

How can you do server-side encryption on IPFS?

[onethought]

No idea. Does this question answer mine?

(Where did you load minibone from in an ipfs context? Couldn’t that same endpoint just perform the encryption?)

[deknos]

Well, you could accept only certain javascript libraries, like with librejs and then it would be fine.

In Theory.

In Practice, no one dares to verify cryptography in the browser, because it's just not possible. but that's not the topic here.