This isn't actually end-to-end encryption, right? You have to trust the server not to corrupt the JS context to exfiltrate secrets. If that's the case (if I haven't misread something here), what is this buying you over just TLS?
There is an attack vector that the server offers a malicious JS file (something which any web based encryptor such as Protonmail is also "vulnerable" to) however this is also possible for other types of application too. App stores can send malicious copies of Signal (both for initial install or (auto-)updates). Future Thunderbird updates can bypass OpenPGP encryption. Dependencies can have malicious backdoors added to affect core encryption libraries.
Trust has to be accepted somewhere along the chain, it's up to you where.
I think the original question is, how is that different to TLS? It seems exactly the same to me.
(Where did you load minibone from in an ipfs context? Couldn’t that same endpoint just perform the encryption?)
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
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.
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.
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?
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.
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.
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.
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.
Yes, you do have to trust the web server(s) in that way so it isn't E2E in that sense. Though with native code E2E you need to trust the source of your app (and subsequent updates) similarly so it isn't entirely different.
You are still protected in cases where a third party attacker gains access to the data but not access to subvert the web server(s) so they send code to perform exfiltration, so there is more protection than with just TLS (or TLS plus plain encryption-at-rest).
Whether this is useful or pointless is going to be dictated by your threat model, though I'd agree it might be worth having some sort of disclaimer stating that the E2E promise might not be as solid as for other systems. Thought said promise may not be as solid elsewhere either: have you verified WhatApp's code at all? (not picking on them intentionally, just plucked them out as the first example that sprang to mind, the question is more valid with less well known services that are less likely to have any worthwhile independent checking/oversight).
And if you turn off automatic updates then you don't get vulnerability fixes. So you're really at the mercy of the people providing your software updates even if we like to pretend that you're not. In the event of something like a world war, theoretical concerns like these would quickly turn into actual concerns.
Not by the specific xz hack that was found. But I guarantee there are a whole lot more that haven't been found. You can't declare victory because we discovered one hacker. Effectively auditing updates for malicious code is impossible both in theory and in practice. As soon as you accept updates you're vulnerable. And if you don't accept updates you're vulnerable because it's impossible to verify that your initial install had no vulnerabilities, either intentional or accidental.
I agree that more frequent updates make a difference, but that difference can easily be in the positive direction too. And I think the overall difference is really not as big as you suggest.
Perhaps it would be useful to have something like a certificate transparency log but for the application code, so it could be retroactively audited on suspicion of foul play, and attacks that supply different updates to different users could be detected by third parties. This would be useful for native apps too.
It is absolutely the same thing as potentially reloading all the code on a regular basis. If you aren't monitoring the updates then "a regular basis" might as well be every time. Turn automatic updates off (but notifications on) on an android device and watch how many apps sometimes update a few times in a short period.
There is a minor gate in that there will be some cursory review of an update delivered via an app store, where a web server can give you updates literally every session or potentially every request, but that cursory check is not enough to give the level of assurance over js from a web server that some take.
> look what happened with xz, and note how you did not in fact get owned
The xz thing could easily have affected a great many people had it not been accidentally discovered. It shows why the app store model could be a concern as much as the js-from-a-web-server app model, not an example of how such gates truly make a difference. It likely would not have been picked up by the screening done in new app releases in a store, and likely nor would some hidden-ish exfiltration code.
The slow update process whereby changes upstream go through testing periods in "unstable" bleeding edge distro variants before getting into the officially stable ones only made a difference by chance. That upstream-to-enduser latency is much lower for E2EE apps in app stores - I'd argue that the risk is much closer to the web server model than the Linux distro model, and the distro model probably very nearly didn't help.
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.
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.
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.
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.