4 ms·

How about a different scenario? Eve is not the threat. Eve is going along serving email for Alice and Bob just fine for quite a while. Then one day Fred compr

How about a different scenario? Eve is not the threat. Eve is going along serving email for Alice and Bob just fine for quite a while. Then one day Fred compromises Eve. Fred can dump data directly out of Eve's database. Depending on how Fred gains access, full disk encryption, database encryption, row-level encryption, etc. might or might not present themselves as layers of security that he must bypass. If Fred has compromised the running service, he will likely have access to the data and any keys, source material needed to derive the keys, or external decryption mechanisms (HSMs, database-side services) from within the service itself. If the messages inside of the database have been encrypted on the clients with keys not held in the server (E2E), Fred now has another layer of defense in front of him, only this one requires Fred to inject script into the clients to scrape the necessary keys. When the client is running Javascript in the browser, this is obviously easier than on clients deployed through some other mechanism, but still more difficult than being able to get everything Fred needs in memory in the server. Mainly, it's another layer of defense, and if the service is using it for other clients, a browser-based client would need to have it to function anyway (even if that weakens the security of the users choosing to use it). An alternate scenario is that Eve is also not a threat, but is instead a business that doesn't want the liability of having certain material in the plain inside of its premises ever.

chii 7y ago
> Eve is not the threat. But Eve is where the attacks are going to come from. Whether it's Eve's intention, or was under coersion by Fred makes no difference to the end user. Browser E2E encryption is at best marginally harder to break, but it gives the user a bigger sense of privacy than it deserves, may be to the detriment of the unlearned user.
- robmccoll 7y ago
  I would argue that collecting keys from all of the user's browsers and dumping the database is more difficult than dumping the database alone, and that makes it worth doing. If as Fred my window of opportunity before I'm detected is small, I might only be able to get keys from users that are active within a small window. I may have to deal with CDN TTLs just to get my code to those users in the first place. The deployment setup might make it a little harder to change the code than just modifying a plaintext file on disk on the server (personally the project I'm working on right now packs static assets into the server binary making them easy enough for Eve to update, but a bit more effort for Fred). In more complex scenarios, there may be many things standing between Fred and injecting code into the browser that aren't in the way of reading the database. It really depends on the specifics of the threat that you're modeling for and how your environment works. For example, if we only focus on scenarios in which we are concerned about an attacker that has wholly compromised the service as you are describing here, we would similarly conclude that TLS serves no purpose as the attacker is already receiving the decrypted data at the other end of the pipe.
Aeolun 7y ago
Defense in depth?
btown 7y ago
> An alternate scenario is that Eve is also not a threat, but is instead a business that doesn't want the liability of having certain material in the plain inside of its premises ever. One great example of this Eve is https://mega.nz https://mega.nz - by design their servers never have access to the encryption key for any uploaded file, and files are shared by including said key in the hash of the URL. This is done for perfect legal deniability of any material on the site. As long as you trust Mega to not alter their code (you can defend-in-depth against this with various methods, including running an open-source client), and you send sharing links only to trusted parties, the content of your data cannot be detected. https://mega.nz/SecurityWhitepaper.pdf https://mega.nz/SecurityWhitepaper.pdf

chii 7y ago

> Eve is not the threat. But Eve is where the attacks are going to come from. Whether it's Eve's intention, or was under coersion by Fred makes no difference to the end user. Browser E2E encryption is at best marginally harder to break, but it gives the user a bigger sense of privacy than it deserves, may be to the detriment of the unlearned user.

robmccoll 7y ago
I would argue that collecting keys from all of the user's browsers and dumping the database is more difficult than dumping the database alone, and that makes it worth doing. If as Fred my window of opportunity before I'm detected is small, I might only be able to get keys from users that are active within a small window. I may have to deal with CDN TTLs just to get my code to those users in the first place. The deployment setup might make it a little harder to change the code than just modifying a plaintext file on disk on the server (personally the project I'm working on right now packs static assets into the server binary making them easy enough for Eve to update, but a bit more effort for Fred). In more complex scenarios, there may be many things standing between Fred and injecting code into the browser that aren't in the way of reading the database. It really depends on the specifics of the threat that you're modeling for and how your environment works. For example, if we only focus on scenarios in which we are concerned about an attacker that has wholly compromised the service as you are describing here, we would similarly conclude that TLS serves no purpose as the attacker is already receiving the decrypted data at the other end of the pipe.

Aeolun 7y ago

Defense in depth?

btown 7y ago

> An alternate scenario is that Eve is also not a threat, but is instead a business that doesn't want the liability of having certain material in the plain inside of its premises ever. One great example of this Eve is https://mega.nz https://mega.nz - by design their servers never have access to the encryption key for any uploaded file, and files are shared by including said key in the hash of the URL. This is done for perfect legal deniability of any material on the site. As long as you trust Mega to not alter their code (you can defend-in-depth against this with various methods, including running an open-source client), and you send sharing links only to trusted parties, the content of your data cannot be detected. https://mega.nz/SecurityWhitepaper.pdf https://mega.nz/SecurityWhitepaper.pdf