All formats described below are implemented in the kernel using dm-crypt, a device mapper target (the kernel also provides cryptoloop, an obsolete disk encryption mechanism). User-space tools such as cryptsetup gather all necessary information (reading config files, reading disk metadata, prompting the user), then configure the kernel's dm-crypt target.
dm-crypt with a raw key
This volume format directly exposes the kernel's dm-crypt target. dm-crypt volumes are managed using cryptsetup (commands other than "luks*"), supplying both the encryption parameters (cipher type, IV generation method) and the data encryption key. This information can be stored anywhere, even entered by the user directly; Fedora/RHEL implement storing this information /etc/crypttab (see crypttab(5)).
This volume format is most useful for swap partitions, where a new data encryption key can be randomly chosen on each system boot; in other situations the data encryption key would have to be stored in a file.
dm-crypt with a password
This is a variant of dm-crypt with a raw key. Instead of specifying the key directly, a password is hashed using an algorithm stored with other metadata of the volume, e.g. in /etc/crypttab.
It's not possible to change the password without reencrypting the volume because changing the password implies changing the data encryption key. Given a data encryption key, the volume can be set up without knowing the password (by treating it as a dm-crypt volume that uses a raw key).
LUKS
LUKS prepends a metadata header to the encrypted volume data. The metadata header stores all algorithm specifications and encrypted keys necessary to access the volume.
LUKS supports up to 8 separate passphrases, by allocating 8 "slots"; each passphrase is processed using PBKDF2 to generate a (slot-specific) key encryption key, which is used to decrypt the data encryption key stored in the slot. The data encryption key is common to all slots, and can't be changed without knowing all passphrases.
LUKS is currently the primary Linux encrypted disk format: anaconda supports creating LUKS partitions during installation; on insertion of a removable disk, GNOME prompts for a passphrase and sets it up automatically.
LVM crypt
LVM crypt is currently under development. It integrates support for the dm-crypt target into LVM, adding support for encrypted metadata into LVM. One advantage of this integration is the possibility to support on-line re-encryption (changing the data encryption key), based partly on existing LVM code to move logical volumes; another is the opportunity to define a very flexible metadata format.
At the top level, a LVM configuration stored on the disk points to a logical volume that stores encrypted data and to an optional logical volume that stores volume metadata. The LVM configuration also specifies a "key specification module" and optional parameters for this module. The module is loaded from the file system, and uses the module parameters and metadata volume (if present) to determine the data encryption key.
Implementation is underway for the following modules:
- A simple module that does not use a metadata volume, stores the encryption parameters in LVM configuration, and the key on a file system. This is similar to using dm-crypt with a raw key.
- A module that uses a LUKS formatted metadata volume and can extract the data encryption key from the LUKS metadata. This can be used to migrate LUKS-encrypted partitions to LVM crypt.
Other volumes could be added, e.g.:
- A module that stores the data encryption key on the metadata volume, encrypted with a key encryption key derived from a TPM key (and optionally a password).
- A module that stores a NSS database in a filesystem on the metadata volume, taking advantage of smart card and other hardware crypto token support in NSS, and storing the data encryption key using this NSS database (e.g. perhaps on a smart card).