Hacker News new | comments | show | ask | jobs | submit login

Many of the techniques can be done at application level. A great example of this that most of us already use in the database is the hashed password.

Wayner's translucent databases book is one of those classic DB works that should be on every dev's bookshelf.

I'm not affiliated with Peter Wayner at all but I've added a separate story to get the word out about his work:

http://news.ycombinator.com/item?id=3373947

But to see what is really unique about CryptDB see this paper:

http://people.csail.mit.edu/nickolai/papers/raluca-cryptdb.p...

We already have a way of checking equality and indexing data safely using digests.

They have come up with similar techniques for ordering encrypted data, performing calculations on encrypted data and doing full text search on encrypted data.

These are all quite amazingly useful to me even though there are definite drawbacks. Eg. an encrypted value that you want to provide calculations on is stored in a 2048 field. But there are definitely great applications for it where it would be worth it.

I am still trying to understand what benefit their DET and JOIN constructs have over just using say a sha256 digest. But I have only skimmed the paper so far.

It would be interesting to see if this can be setup on an ec2 instance proxying towards an RDS instance. I don't from the outset see why not.




The DET construct (and this might apply to the JOIN as well, I don't remember) is most useful with symmetric key encryption since then you can use in inside one of their "onions". You couldn't peel off the DET layer to get more functionality if it was stored as a digest, since those are only one-way.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: