In a word: sufficient.
This is block-level encryption, so it is filesystem-independent.
Ubuntu's transparent encryption is done through
LUKS as the key setup. The built-in default for
cryptsetup versions before 1.6.0 is
aes-cbc-essiv:sha256 with 256-bit keys. The default for 1.6.0 and after (released 14-Jan-2013) is
aes-xts-plain64:sha256 with 512-bit keys.
For older versions of
- AES you certainly know; it's about as good a cipher as you could want.
- CBC is the chaining mode; not horrible but certainly not what I would pick for new projects: it has several issues but it can be used securely.
- ESSIV ("Encrypted salt-sector initialization vector") allows the system to create IVs based on a hash including the sector number and encryption key. This allows you to jump straight to to the sector you want without resorting to predictable IVs, and therefore protects you from watermarking attacks.
- SHA-256 is the hashing algorithm used for key derivation. LUKS uses PBKDF2 to strengthen the key for (by default) a minimum of 1000 iterations or 1/8 second, whichever is more. On a fast computer, expect around 200,000 iterations. With respect to security, you couldn't ask for a better arrangement.
And with newer versions of
- XTS is counter-oriented chaining mode. It's an evolution of XEX (actually: "XEX-based tweaked-codebook mode with ciphertext stealing"), while XEX ("xor-encrypt-xor") is a non-trivial counter-based chaining mode; neither of which I can claim to completely understand. XTS is already very widely supported and looks promising, but may have issues. The primary important details are these: No fancy IVs are necessary (
plain64 is fine), and half of your key is used by XTS, meaning your original key must be twice as long (hence 512-bit instead of 256-bit).
- PLAIN64 is an IV generation mechanism that simply passes the 64-bit sector index directly to the chaining algorithm as the IV.
plain truncates that to 32-bit. Certain chaining modes such as XTS don't need the IV to be unpredictable, while modes like CBC would be vulnerable to fingerprinting/watermarking attacks if used with plain IVs.
Other options not used by default
- LRW has been largely replaced by XTS because of some security concerns, and is not even an option for most disk encryption products.
- benbi calculates a narrow-width block count using a shift register. It was built with LRW mode in mind.
Altogether, this makes for a pretty tight system. It isn't the absolute best system theoretically possible, but it's pretty close. You should be able to trust it in any reasonable circumstances as long as your password is sufficient. Your attacker will almost certainly choose brute-forcing the password as his preferred attack method.