On Mon, Dec 23, 2013 at 03:47:05PM -0500, Robert P. J. Day wrote: > it *seems* that eCryptfs is an improvement over LUKS. is that > accurate? No. > or are they equally viable technologies so that one could reasonably > choose one or the other depending on the circumstances? Yes… and no. One does **block device** encryption, the other is a stacked cryptographic **filesystem**. Personally, I just encrypt everything but the boot partition nowadays so I may not be the best judge. You could though use eCryptFS for transparent encryption of all files under a directory on somebody's portable drive, a network filesystem mount [1], etc. It's also suboptimal to do encrypted swap using eCryptFS. eCryptFS is mounted on top of a directory, transparently encrypting further operations within the directory, and storing the transformed data into another directory of your chosing. If I recall correctly, operations on items under the directory prior to the use of eCryptFS are undefined. LUKS does block device symmetric encryption. It's in a way a wrapper around dm-crypt. Plain dm-crypt requires you to specify all the parameters manually, whereas LUKS creates a header at the beginning of the block device. dm-crypt requires you to understand the crypto, and won't do things like salting your secret. LUKS will randomly generate (and salt if I recall correctly) a master secret, and provide ten “slots” for weaker secrets (e.g., passwords, passphrases, or binary data of your chosing), which it'll run through PBKDF2. > put another way, i have to teach some basic encrypted filesystems > as part of an admin course in january, and i'm wondering if i should > cover both technologies, or simply the *better* one. at the moment, > i suspect i should cover both, just to play it safe. Cover both. “Full disk” encryption is likely (don't know how many people still use loop-AES or TrueCrypt) typically done using LUKS whereas selective encryption (such as some users' home directories by Ubuntu) is done using eCryptFS. 1: Hopefully primarily to deal with insecure storage on the remote end, not to secure the transport, something which would be better done using TLS or IPsec.