51–60 of 73 posts
Earlier quoted context omitted.
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.
How can you do server-side encryption on IPFS?
(Where did you load minibone from in an ipfs context? Couldn’t that same endpoint just perform the encryption?)
Earlier quoted context omitted.
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.…
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 t…
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.
Earlier quoted context omitted.
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.…
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 revers…
Earlier quoted context omitted.
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 t…
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 sug…
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?
Earlier quoted context omitted.
It's end-to-end in the fact that it's encrypted and decrypted client side with the server only seeing ciphertext. With TLS, third party observers see ciphertext but the server sees plain text. 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 sto…
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.…
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.
Earlier quoted context omitted.
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 sug…
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?
I'm a little skeptical about this: - If I don't trust you with my data, why would I trust you to serve me the library I use to encrypt my data? - I don't think it's possible to restrict parts of your JavaScript env from a server, so even if I get minibone from a CDN, check the hash, and encrypt things clientside the unencrypted stuff lives somewhere, or the server can setup hooks to grab it before I clean it up, etc.…
> If I don't trust you with my data, why would I trust you to serve me the library I use to encrypt my data? Because trust has to be given somewhere and my business would likely fail if I'm telling you it's encrypted but actually it's not. Plus, if you were really concerned you could open up the developer tools, network tab and see the communication to the server and validate that it's only sending encrypted data tha…
Earlier quoted context omitted.
It's end-to-end in the fact that it's encrypted and decrypted client side with the server only seeing ciphertext. With TLS, third party observers see ciphertext but the server sees plain text. 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 sto…
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.…
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.
Earlier quoted context omitted.
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.…
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 update…
Earlier quoted context omitted.
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?
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.
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.