[ihaveyourbuns]

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.

[sirclueless]

You're thinking at the wrong level. The password that encrypts a user's credit card data is almost certainly not the password a customer logs in with. It's some highly controlled password that only some privileged authentication server knows.

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.

[mike-cardwell]

It's not suitable for all data. That doesn't mean that it isn't suitable for any data. When credit card payments are user initiated rather than automatic, it could have value.

[RobAtticus]

There are two modes presented in the paper: single-user and multi-user. In single user, the proxy has a master key in which it derives all other necessary encryption keys from. In multi-user mode, keys are generated from a user's password and the database schema is annotated to identify who's keys can decrypt which data.

So for your proposed example, you would likely run in single user mode and it would work just fine.