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.<p>Wayner's translucent databases book is one of those classic DB works that should be on every dev's bookshelf.<p>I'm not affiliated with Peter Wayner at all but I've added a separate story to get the word out about his work:<p><a href="http://news.ycombinator.com/item?id=3373947" rel="nofollow">http://news.ycombinator.com/item?id=3373947</a><p>But to see what is really unique about CryptDB see this paper:<p><a href="http://people.csail.mit.edu/nickolai/papers/raluca-cryptdb.pdf" rel="nofollow">http://people.csail.mit.edu/nickolai/papers/raluca-cryptdb.p...</a><p>We already have a way of checking equality and indexing data safely using digests.<p>They have come up with similar techniques for ordering encrypted data, performing calculations on encrypted data and doing full text search on encrypted data.<p>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.<p>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.<p>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.
30 degrees off-topic, but sqlite was extended to support encryption. <a href="http://sqlcipher.net/" rel="nofollow">http://sqlcipher.net/</a><p>It has been a fascinating evolution personally to write software that creeps on the border of sqlite not being quite enough. (Which probably speaks to the design, but still, it seems like a rite of passage).
The link is a bit light on information, so I cloned the repo and pasted the README file from it here:<p><a href="https://pastee.org/323xe" rel="nofollow">https://pastee.org/323xe</a><p>Basically, from the looks of it, it seems to run as a proxy inbetween your client software and the MySQL database.
i guess it's useful to keep this data from a db admin, but whoever admins the server that encrypts the data must have access to the encryption key(s).<p>it does further restrict who can access data which is good and it seems to come at a serious cost in complexity. if your db admin is bleeding company data i think your problems are just beginning...
Nice try MIT, but I don't really see this useful in the real world. Typically data that needs to be encrypted must be accessed by system processes to make any application useful. For example you want to encrypt the contact email, but you want to send automatic alerts to that email or a system needs to do an automatic credit card payment. Those are hard to do when you need the users password to decrypt the data.