How does this work without exposing the client keys in server memory? You still need to send the server your private key to query and decrypt data you specifically didn't make via other connected clients, right?
Edit: I phrased that wrong. How do you usefully query other user's data with only your keys?
Nope, query logic happens on the client, so server doesn't know the key. Client is the one who records data and indexes encrypted, and who uses indexes from remote.
It is scalable enough because you need to download log(index_size) rather than full index.
The use case - any private data which you'd like to encrypt on the server while preserving ability to search. Medical records, financial data, emails are some examples.
Easier to say what this database is not for. Big data applications where you need to use a significant portion of data in the db (like 10%) in map-reduce queries is probably not what ZeroDB would be practical for.
I appreciate the answers. I'm genuinely curious because I've contemplated such a database on the side but could never see my way to the goal.
The final outstanding question I have though is: How do you deal with data you aren't the owner of? Is this strictly targeted at scenarios where you are the sole owner?
Good question. We thought about two cases. One is when your are sole owner of the data.
The other is when the owner of the data is some group (like JP Chase). In this case we can have server-side quotas for handling cases when one or several clients are compromised. So, in this case it's more about distributing trust
Comments
How does this work without exposing the client keys in server memory? You still need to send the server your private key to query and decrypt data you specifically didn't make via other connected clients, right?
Edit: I phrased that wrong. How do you usefully query other user's data with only your keys?
Nope, query logic happens on the client, so server doesn't know the key. Client is the one who records data and indexes encrypted, and who uses indexes from remote.
Which doesn't sound very scalable at all. What is the use case for this?
It is scalable enough because you need to download log(index_size) rather than full index.
The use case - any private data which you'd like to encrypt on the server while preserving ability to search. Medical records, financial data, emails are some examples.
Easier to say what this database is not for. Big data applications where you need to use a significant portion of data in the db (like 10%) in map-reduce queries is probably not what ZeroDB would be practical for.
I appreciate the answers. I'm genuinely curious because I've contemplated such a database on the side but could never see my way to the goal.
The final outstanding question I have though is: How do you deal with data you aren't the owner of? Is this strictly targeted at scenarios where you are the sole owner?
Good question. We thought about two cases. One is when your are sole owner of the data.
The other is when the owner of the data is some group (like JP Chase). In this case we can have server-side quotas for handling cases when one or several clients are compromised. So, in this case it's more about distributing trust