41–50 of 73 posts
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?
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.…
The ideal solution would be a web api. Seems like this is only available low level with a “don’t use this to roll your own” disclaimer. What would be ideal would be a string->byte[] function in the web api that encrypts (and one that decrypts) with key management delegated to the browser.
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?
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…
There seems to be a lot of skepticism in the comments but I can definitely see a use-case for this (I have no relationship to the project). Ultimately, plain text data should never reach the server and the server will never have access to decryption keys either. Row level encryption; encryption at rest etc. is not the same as in those cases the data arrives at the server in plain text which can end up in logs, can be…
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.…
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.…
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.
I think the original question is, how is that different to TLS? It seems exactly the same to me.
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.…
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
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?
What meets your e2e standard? You can always corrupt the client, even an update in a mobile app. I agree JS is more vulnerable to extensions attacks or XSS or supply chain of some other dep you included.
Earlier quoted context omitted.
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.
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.
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.…
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.