You can't trust the infra; Encrypt client side

jve.linuxwall.info

10 points·jvehent··4 comments

Montasano has been vocal in the past about denouncing client side crypto implemented in javascript [1], but I think that their use cases fail to consider a system in which the server has no need to access the decrypted user data.

I helped implement a system for Stellar that does something very similar to what this article describes [2]. User data is encrypted into blobs using a key generated from credentials. The blob is fetched from the server using a hash of those credentials. Neither the server nor a MITM have sufficient information to decrypt your blob, so the security is deferred to each user's computer.

If you want a server to be able to access your data, you must acknowledge that there is a non-zero probability that it will become public. If you want truly private data you must encrypt it locally and take the appropriate measures to keep your local system secure.

[1] https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...

[2] https://www.stellar.org/blog/wallet-server-version-two-the-e...

If the server cannot be trusted, it will extract your encrypted data, since it serves up the code. The server, if compromised/subpoenaed, merely needs to serve you some JavaScript that sends home the encryption key, and your data is no longer just your data.

The redeeming quality is that compromised servers are usually detected and shutdown quickly. Traditional servers are dumped and the data is compromised. Encrypted blob storage makes the dump nearly impossible to decrpyt.

It's OK to improve security incrementally. Better security is the path to the best security.

Compromised servers are detected and shutdown quickly? [ Citation needed ]

Reply on news.ycombinator.com