How to improve performance of encrypted MySQL database on Linux backend server?

Full Disclosure: I am Gazzang's Chief Architect, as well as one of the authors and the current upstream maintainer of the eCrypfs encrypted filesystem.

Hi @Dan,

ezNcrypt is a commercial product sold by my employer, Gazzang. It is built on top of eCryptfs, an open source encrypted filesystem built into the Linux kernel and with user space utilities available in all major Linux distributions. I'll try to address your question in an unbiased manner :-)

eCryptfs is 100% GPLv2 free software. It's a mature encrypted filesystem widely available in Linux. An estimated 3 million Ubuntu desktop users use eCryptfs through Ubuntu's Encrypted Home Directory feature. Each file is individually encrypted (juxtaposed against device-mapped full-disk and full-partition encryption). eCryptfs minimizes the performance penalty as compared to some other encryption options, as noted in this report from Phoronix, and this design document from Google's ChromeOS which uses eCryptfs. If you know what you're doing (or with a fair bit of independent research), you could almost certainly accomplish the encryption of your MySQL database using eCryptfs while minimizing the performance impact. It will take a fair amount of effort, and your configuration will have limited quality assurance and reproducibility, though I know many people using eCryptfs for far crazier use cases!

ezNcrypt includes an open source (GPLv2) DKMS kernel module, but a proprietary user space sold as a licensed commercial product from Gazzang. With the commercial license, customers receive first class customer support and suite of utilities that make encrypting any database (including MySQL) much, much "easier" as the name implies. At the lowest level, ezNcrypt is still using eCryptfs, but the thoroughly-tested, database-targeted suite of tools is a for-pay, commercially supported product.

What would speed things up would be to have sensitive fields encrypted using the Advanced Encryption Standard (AES) on a system with an AES-Instruction-Set-(IS)-capable CPU, preferably with 256-bit keys, preferably in Ciper-Block Chaining (CBC) mode or, at least, Electronic Codebook Mode (ECB) with a salt - this can be done by simply prepending at least 1 character / byte to the data to be encrypted.

What would be even more secure would be to encrypt everything except /boot with AES in Extended Schedule with Ciphertext Stealing (XTS) mode in addition so sensitive fields in the database. You can use TrueCrypt to encrypt an entire disk, partition, or simply a TrueCrypt container in this manner - however, I would recommend system encryption so that no one can see the PHP (?) code containing the encryption key if your disk(s) get(s) stolen.

A known-plaintext brute-force attack on an AES key for data encrypted in ECB mode on a Cray XE6 with 1 million Opteron 6200-series chips would take at most 1.34188978904574248034587874518e+71 years just for the AES-NI instructions. Doing it on a Cray XK6 would place it at somewhere around 1.34e+69 years at most. This is, however, merely a brute-force attack, without breaking AES. Partially breaking AES would speed it up exponentially.

The most important thing is to use a complex pass phrase. This means that it has to be either a long string of a small set of characters (e.g. the letters of the English alphabet) or a short string of, basically, random bits whose byte value is not zero (null-terminator). Using an up-to-8-characters-long pass phrase consisting of the letters of the English alphabet places a brute-force attack on data encrypted with AES at below 10 seconds on a Cray XE6 with 1 million Opteron 6200-series chips and below 100 miliseconds on a Cray XK6. See Non-dictionary known-plaintext brute force attack on AES-256.

Even more secure would be to use something other than AES with a hardware accelerator, because AES acceleration is widely available. Even more secure would be to use both.