3 ms·

I understand what you mean by "zero knowledge", but it bothers me when companies say things like "we can't access your data because it's encrypted client-side".

I understand what you mean by "zero knowledge", but it bothers me when companies say things like "we can't access your data because it's encrypted client-side". If the service provider controls the code in the client (as you do), the fact is the service provider definitely can access the data, you're just choosing not to. I don't think there is much difference between encrypting client-side when you control the client, and encrypting server-side before storage. Either way you have encryption-at-rest.

angry_octet 10y ago
There is a difference, and its about how the data is going to leak out. If the access can only happen via a key stored on the client, the client somehow has to supply that to the attacker (whether an official attacker or not). If every user's key and data are stored on the server then a compromise of every (or any) user becomes much more feasible. There isn't really a problem of data at rest being stolen (except for laptops/cell phones/usb sticks), it is stolen while live. Overall though I would agree that you can't trust it much, because some code is downloaded from the server and then you trust that code (which can communicate with the server) with the key... Perhaps if it was in a local sandbox whose policies were enforced in a browser pref, or there was taint analysis applied to sensitive local data. In years to come people will snicker at how wide open and insecure things were back in 201x.
- aboodman 10y ago
  If you store the keys, sure, that's less secure for sure. But just because you encrypt server side doesn't mean you store keys. What's the difference between: 1. Get key from user on client 2. Encrypt on client 3. Discard key 4. Discard unencrypted data 5. Send encrypted data to server 6. Store encrypted data and: 1. Get key from user on client 2. Send key and data to server over SSL 3. Encrypt on server in response handler 4. Discard key 5. Discard unencrypted data 6. Store encrypted data There are some differences, but I don't think it's clear which one is "better". I think it would depend on the details. Big picture: either way the developer sees the key and the unencrypted data. Either way, you are completely trusting the competence of the developer at implementing this scheme, and their trustworthiness with the key and unencrypted data. There is no such thing as "host-proof" encryption as long as the client is provided by the host.

angry_octet 10y ago

There is a difference, and its about how the data is going to leak out. If the access can only happen via a key stored on the client, the client somehow has to supply that to the attacker (whether an official attacker or not). If every user's key and data are stored on the server then a compromise of every (or any) user becomes much more feasible. There isn't really a problem of data at rest being stolen (except for laptops/cell phones/usb sticks), it is stolen while live. Overall though I would agree that you can't trust it much, because some code is downloaded from the server and then you trust that code (which can communicate with the server) with the key... Perhaps if it was in a local sandbox whose policies were enforced in a browser pref, or there was taint analysis applied to sensitive local data. In years to come people will snicker at how wide open and insecure things were back in 201x.

aboodman 10y ago
If you store the keys, sure, that's less secure for sure. But just because you encrypt server side doesn't mean you store keys. What's the difference between: 1. Get key from user on client 2. Encrypt on client 3. Discard key 4. Discard unencrypted data 5. Send encrypted data to server 6. Store encrypted data and: 1. Get key from user on client 2. Send key and data to server over SSL 3. Encrypt on server in response handler 4. Discard key 5. Discard unencrypted data 6. Store encrypted data There are some differences, but I don't think it's clear which one is "better". I think it would depend on the details. Big picture: either way the developer sees the key and the unencrypted data. Either way, you are completely trusting the competence of the developer at implementing this scheme, and their trustworthiness with the key and unencrypted data. There is no such thing as "host-proof" encryption as long as the client is provided by the host.