
ZeroDB, an end-to-end encrypted database - mwilkison
http://blog.zerodb.io/hello-world-zerodb-here/
======
akerl_
This feels like a hollow announcement, given that there's no code or design
details to look at.

I am curious how they intend to let a client run queries against a dataset
that the server cannot read without the server having to send all the
encrypted data over the wire, or at least an index of all the encrypted data.
Which sounds limiting for large datasets.

~~~
anologwintermut
Not sure how they do it, but it has been done before as a research project
[http://css.csail.mit.edu/cryptdb/](http://css.csail.mit.edu/cryptdb/). One of
the tricks it uses(though by no means the only) is to do a binary search in an
index, it actually has the client decrypt a node and compare and then give the
server the result.

~~~
michwill
Re-read their paper about mOPE. Very similar indeed. The difference is that in
our case the server doesn't know the tree structure, with cryptdb it does.

~~~
swordswinger12
So you use a scheme similar to mOPE? How do you handle tree rebalancing? Is
your variant of mOPE deterministic?

~~~
michwill
Well, actually we don't use determenistic encryption, and the server knows
nothing about ordering. It merely stores the trees and returns requested
pieces (w/o knowing which piece is that or is it a piece of a tree at all).

I find some ideas in MIT mOPE paper similar though

~~~
swordswinger12
I didn't ask whether you use deterministic encryption, I asked whether your
variant of mOPE is deterministic. It's possible to use randomized encryption
for the leaves of mOPE and still construct a deterministic OPF.

EDIT: Also, you say the server does not know the tree structure. Do you mean
it doesn't know the structure until you query, or the structure is always
obfuscated (including access patterns and search patterns)?

EDIT2: What is the round complexity of a single query in your protocol?

------
michaelmachine
How does this compare to CryptDB
[http://css.csail.mit.edu/cryptdb/](http://css.csail.mit.edu/cryptdb/) ?

------
bcg1
I realize that your post was titled "Hello World" so I wouldn't expect too
much substance, but a couple quick questions (honest ones, not being
sarcastic):

What is the use case for something like this?

Is this f/oss ... similarly, what are the licensing terms?

Quick comment:

Please don't misuse the word "hack" when you actually mean "security breach".
Thanks!

~~~
michwill
The use-cases could be, for example, payment processors storing customer data,
encrypted webmail (where you're able to search w/o downloading all your
emails), "encrypted evernote" :-)

Yes, it will be open source once available

~~~
bcg1
Oh, sounds good. So even though you can't get at the data on the server, you
are able verify that it is unchanged with correct timestamps, etc. Sounds
smart, useful. I presume then that you can support searching on the client
side by downloading an encrypted index or something like that?

Thanks for the good work guys, best of luck with your project and (ad)venture.

~~~
michwill
We support client-side search, that' the whole point. But we don't even have
to download all the index, only log(index_size)

~~~
mcintyre1994
That's for full text search? This sounds really cool! Excuse the not-very-
sophisticated question because I'm not really familiar with the data
structures a database typically uses, how do your index sizes compare to a
typical sql database or similar indexed similarly for the same sort of
queries?

~~~
michwill
Index sizes are pretty similar (consider the same).

Having the index end-to-end encrypted imposes some limitations though. You
have to do several requests when you want to do one query which is obviously
slower. Though, still practical.

And since the CPU logic happens on the client, in some cases (many
simultaneous clients) the performance can be actually better.

------
elchief
Database encryption doesn't make a whole lot of sense to me. Proper row and
column security, and using real database user authentication (not one single,
pooled web server user) is real security. A db on its own box, in its own
network zone, physically controller by the data owner.

What's the threat here?

SQL Injection? Encryption won't help. Use parameterized queries and least
privilege.

Evil admin? They can just monitor the web server instead of the db.

~~~
michwill
Appications should be architected so that security-critical logic happens on
the client. See how Mega and SpiderOak do that. This way, the attacker has to
hack every computer of every client instead of one single server.

Of course, this requires making sure that the code which the client executes
is not malicious

~~~
undefined0
I can see this being useful for the example you gave, Mega. Currently, the
list of files you upload are all downloaded to the client in order to do a
search. If the search could happen on the server but the file list remains
encrypted, that would make the website less costly for the client.

------
rubbingalcohol
This is an amazing promise, but I was sad this is just a beta signup. I would
really love to play around with something like this, and would also like to
know how it works.

Don't play with my heart, ZeroDB. Show us what you've got!

~~~
michwill
We will release it open source once it's ready to be used, together with a
whitepaper. Which, I hope, will happen pretty soon!

~~~
incomethax
This could be a really BIG deal for healthcare if you do it well. I would love
to have a completely encrypted db that I could setup dynamic failover and
replication. Also an amazing additional feature would be if it contained
built-in access logging.

If you were to do that, HIPAA becomes MUCH easier for other healthcare IT
startups using your db.

~~~
michwill
Thanks a lot for the hints! :-)

------
hasenj
Kind of interesting but I would like to see an explanation of the idea and how
it works. The demo video doesn't seem to show any sign of encryption.

------
BinaryIdiot
Alright even though it's light on information you've certainly caught my
attention. Is there a GitHub page setup yet that I can follow?

------
superobserver
Interesting. I wonder how it will turn out to compare with ProtonMail's
solution.

~~~
michwill
Yes, interesting. I wonder how did they implement search over there

------
bobofettfett
1\. Good, all DB data needs to be encrypted 2\. That said, the largest
security risk is applications (backends) that enable mass access to customer
data and allow mass leaks of customer data.

------
alimoeeny
Some technical detail would be much appreciated, like the language you are
using on the server side, any dependencies? Road map for when you are open
sourcing it (I assume you will do)...

------
axx
Sorry for asking, but if the private keys are stored client-side, how do
handle users with multiple computers? Let the user handle it by hand?

(i'm no encryption expert, just curious)

~~~
hasenj
I think the "client" here is the application server, not the web browser.

~~~
axx
Then where's the point in this?

~~~
michwill
Your [pretty long] passphrase can be your key. Or you can take your key file
with you.

Having the key derived from your password is also possible, but I think not
really that secure.

SpiderOak and Mega deal with this problem as they have e2e encrypted file
storage

------
peterboo
hi there. this concept has already been developed at : [http://spot-
on.sf.net](http://spot-on.sf.net) and is also deployed in
[http://goldbug.sf.net](http://goldbug.sf.net)

