To protect the content of your disk against unwanted reading even if the machine is stolen, it can make sense to encrypt the disk. This section discusses Linux support for disk encryption and the impact this has on the initial boot image. The idea here is to encrypt the entire disk with a single key: the kernel encrypts and decrypts all blocks on an underlying device and presents it as a new ordinary block device, where you can use mkfs and fsck as always. Thus an encrypted disk only protects the confidentiality of your data in cases where the hardware is first switched off and then taken away for later perusal by the bad guys. It will not protect confidentiality if the bad guy gains access to a running system, either through an exploit or with a valid account. There are different implementations of this idea. All implementations use the kernel crypto modules (the same stuff that supports IPsec), but they differ in how that cryptography is squeezed between userland and the diskplatter.See GDBE for a similar mechanism under BSD. Note that we do not compare how effective the various implementations are at keeping your data secret: if your data is important enough to encrypt, it's also important enough to do your own research into which implementation is most robust. cryptoloop Is in mainline kernel 2.6.10, but has reliability problems, such as possible deadlocks. The cryptoloop maintainer: "We should support cryptoloop. No new features, but working well. At the same time we should declare it 'deprecated' and provide dm-crypt as alternative." See kerneltrap for background. The on-disk format is trivial: just the encrypted data. When the device is initialised, the user enters a passphrase and a hash of this phrase is used as key to do the decryption, and if the result is a filesystem, the key was valid. dm-crypt Is in mainline kernel since 2.6.4. It uses device mapper (the same framework that is also used by LVM), which makes it more stable than cryptoloop. See dm-crypt: a device-mapper crypto target. Dm-crypt can use the same on-disk format as cryptoloop, but the device mapper makes it easy to reserve part of the disk for a partition header with key material. Such a partition header, LUKS, is now under development; it will offer improved protection against dictionary attacks and will make it easier to change the password on an encrypted disk. Due to the way the device mapper works, support for the partition header can be implemented completely in userspace. LUKS is integrated in Gentoo and included in Fedora FC4 test1. A debian package exists (cryptsetup-luks), but is not (yet) included in the main archive. loopaes An encrypting loop device; see http://loop-aes.sourceforge.net, http://mail.nl.linux.org/linux-crypto/. It's not in mainline kernel, and the author has no intentions of pushing it in. All these implementations need some kind of userspace tool to pass key material to the kernel; this key material may come from lots of places: in the most simple case, it could be a hashed version of the password it could be a large random key stored in a gpg-encrypted file for swap devices, it could be randomly regenerated on each reboot for file systems other than the root, it could be from a file with mode 600 on the root file system the key could be stored on a USB stick, stored separately from the machine. An overview of relevant userspace tools: the losetup command has an encryption option to use the cryptoloop module. Note that this does not cause cryptoloop to be mounted automatically. versions of the mount command in Debian and Fedora have a 'loop,encryption' option that will be passed to losetup for use with cryptoloop, like so: /dev/vg0/crwrap /crypt1 ext3 loop,encryption=aes,noauto 0 0 The dmsetup command can set and show parameters (including key hashes!) for dm based devices, including dm-crypt and LVM. With a bit of shell scripting, you can hash a password and pass it on the command line to set up a dm-crypt device. # : dont bother cracking this key, its a dummy # dmsetup table crypted: 0 2097152 crypt aes-cbc-plain \ e9975dcb10992fbc03a52f44e8f830d8e997\ 5dcb10992fbc03a52f44e8f830d8e9975dcb\ 10992fbc03a52f44e8f830d8 0 254:7 0 vg0-crwrap: 0 2097152 linear 8:3 56623488 # The cryptsetup command adds a friendly wrapper around this. In particular, it has hashing of the keyword built in. A modified package cryptsetup-luks exists, that adds extra options to (1) create a luks headers for a partition and (2) open a partition given one of a number of possible passphrases. The file /etc/crypttab is a debian extension to cryptsetup: it provides a list of crypted devices, their underlying devices, corresponding cipher and hash settings, plus the source for the passphrase: either some file or the controlling terminal. This allows the devices to be activated by /etc/init.d/cryptdisks. There is a thread on adding /etc/crypttab to Fedora: too late for FC3, to be considered again for FC4: see here and here. In order to activate an encrypted device with cryptsetup, we need to detect: which underlying device to use which encryption and hash algorithm to use where the passphrase comes from whether we have a plain crypted partition from LUKS partition In order to determine all these points we need information from /etc/crypttab; as a consistency check, we'll compare this to the output from "cryptsetup status". The output from "dmsetup table" would be an alternative. It's easier to parse, but introduces an additional package dependency. The resulting actions: If the source of the passphrase is something other than the console, abort. There are too many variables to support this reliably. For the passphrase hash algorithm, no modules need to be loaded, since it is included by cryptsetup from a user space library. Make the underlying device available. Modprobe the dm-crypt and the cipher (the module name is the part of the cipher name before the first hyphen). If the cipher block mode needs a hash, load that too. Note that the cipher block mode hash is something different from the passphrase hash: it's the part after the colon in eg 'aes-cbc-essiv:sha256'. For plain cryptsetup, invoke an action with the following parameters: cryptsetup target=device src= ... hash= ... cipher= ... size= ... verify=y|undef Here the cryptsetup action will result in a script fragment in /init that has "cryptsetup create" in a loop until exit status is 0. For plain cryptsetup, this only has effect in combination with the "verify" option: exit status is 0 is the user gives the same password twice in succession. With cryptsetup-luks, this would test that the passphrase actually gives access to the encrypted device. For cryptsetup-luks, invoke a similar action with fewer parameters, since so much of the required information is already in the header.