search

nucypher / zerodb

*This project is no longer actively maintained. If you'd like to become the maintainer, please let us know.* ZeroDB is an end-to-end encrypted database. Data can be stored and queried on untrusted database servers without ever exposing the encryption key. Clients can execute remote queries against the encrypted data without downloading all of it or suffering an excessive performance hit.
GNU Affero General Public License v3.0
1.56k stars 102 forks source link

Whitepaper #6

Closed michwill closed 8 years ago

michwill commented 8 years ago

Whitepaper about current status and where zerodb is headed is requested.

I think I understand correctly that zeroDB serves up encrypted index information and encrypted records, allowing clients to acquire data (leaking access information) through probably log-depth number of iterative queries. What I don't see is an adversarial model or any cite of underlying theory - is that available somewhere? The related fields of PIR, PPSSI, SSE, etc are rather rich and all in agreement that the trade-offs are numerous while the security assurances are nuanced by shockingly important. As such, I'd really like to have a solid understanding of what ZeroDB is now and where it is headed.

tom-md

More ideas about what to write in the paper

I would defintely be interested in more detail of the theoretical robustness of ZeroDB. Presumably we are using ZeroDB because we're not completely confident in the security of the server. e.g. it's a VPS in the US and the NSA has just turned up with a national security letter. I'd be keen to have some ballpark for an extremly long time as it relates to the number of queries, data size and block size on the server. (I'm assuming all these points will be related) Let's say the VPS has been compromised and the ZeroDB program has been replaced with a compromised version. What's the worst case scenario? Timing attacks on the client to deduce keys? I'd also like to point out your documentation says the server never has any knowledge about the data structure but you now tell me it does leak (however slightly). I would prefer to see that in the documentation. I'm aware that I might be coming off as a bit of a pedantic git here, but security is insanely hard and the only way to do it right is to let people ask the difficult questions and hit it with a stick a few times. Mulling this over, another question I'd like to see addressed is: Can the server guess if two clients issue the same query by the access pattern. Again I would expect a the block size to affect confidence.

tea-drinker

Consider threat of DDOS attacks

I feel like this is a dangerous model for a DB. Mainly because a XSS would give an attacker full access to the user's encrypted data. In a traditional db model, that is prevented by not exposing the entire database and rather a subset of database operations based on context. Further, I would be really concerned about DDOS type attacks, which seem to be really easy to do if your client is the thing sending the queries. The client could craft some pretty nasty queries that could really kill the DB, especially where the model is basically the client saying "Here, give me this block of data". That could create a ton of network traffic and disk traffic, pretty easily.

cogman10

michwill commented 8 years ago

Whitepaper is out. Even though, there are still some issues to address in its next versions