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:
But to see what is really unique about CryptDB see this paper:
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.
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).
Basically, from the looks of it, it seems to run as a proxy inbetween your client software and the MySQL database.
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...
Right now, if you want to store sensitive data, you basically have to do it all in-house, which costs big money (think of all the PCI regulations you have to satisfy and auditors that you need to pacify).
This doesn't just defend the data from unscrupulous sysadmins, it also defends data from hackers who manage to gain access and run a mysqldump.
My understanding is that CryptDB offers no protection from attackers who sit between the proxy and the web server. Obviously the web server (or other client) must deal with plaintext, otherwise application software would require changes. The authors of CryptDB assert in no uncertain terms that this is a drop in solution that requires zero application changes, therefore the proxy must do all the work.
The idea is to run the proxy on a different machine than the database, thus allowing the maintenance of the database server's hardware, OS, and RDBMS software to be outsourced without providing access to your data. No amount of monitoring of traffic between the proxy and the RDBMS should matter.
The weakest part of this system is that is appears to store the data in the database with different types of encryption that allow for various operations to be performed on the cipher text. I think that anyone who controls the database system can obtain some of the weaker cipher texts of the data and possibly break them.
I really can't be sure until I test it out... I'm kinda disappointed that it doesn't come with quick instructions to get it going on postgres.
The goal is to reduce the attack surface, and prevent incidental discovery of data. For example, I could set up a server that manages high security passwords and only grant access to a select few trusted people. I have to carefully audit how that server gets used, and who can use it, but I can let any old DBA mess around with all my encrypted data. I can throw it on any old server, I could outsource it to some cloud hosting company, it doesn't matter. That's a huge win in some industries. The only thing I need to trust now are the servers with credentials and the CryptDB software itself, I don't need to care about the data itself.
So for your proposed example, you would likely run in single user mode and it would work just fine.