This knowledge article addresses the following questions, and more.

• What is LUKS? cryptsetup? dm-crypt?
• What is the difference between cryptsetup plain and cryptsetup LUKS?
• What packages are required for LUKS in Red Hat Enterprise Linux?
• How can LUKS HDD-encryption be accomplished in Red Hat Enterprise Linux?
• What cipher does LUKS use to encrypt a disk?
• How big are the encryption keys LUKS uses? Can this be changed?
• Why do devices encrypted with cryptsetup use a different mode than devices encrypted at install-time?

dm-crypt and cryptsetup

• Device-mapper is a part of the Linux kernel that provides a generic way to create virtual layers of block devices, most commonly LVM logical volumes. The device-mapper crypt target (dm-crypt) provides transparent encryption of block devices using the kernel crypto API (supporting ciphers and digest algorithms via standard kernel modules).

• In Red Hat Enterprise Linux, userspace interaction with dm-crypt is managed by a tool called cryptsetup, which uses the device-mapper infrastructure to setup and operate on encrypted block devices.

LUKS

• With modern versions of cryptsetup (i.e., since ~2006), encrypted block devices can be created in two main formats, plain dm-crypt format or the extended LUKS (Linux Unified Key Setup-on-disk-format) format. LUKS provides a standard on-disk-format for hard disk encryption, which facilitates compatibility among Linux distributions and provides secure management of multiple user passwords. In contrast to previous Linux disk-encryption solutions, LUKS stores all necessary setup information in the partition header, enabling the user to more easily transport or migrate their data.

Plain format versus LUKS format

• Plain

  • Plain format is just that: It has no metadata on disk -- when using any such encrypted device, all the necessary parameters must be passed to cryptsetup from the commandline (otherwise it uses the defaults, which will only succeed if the device was created using default settings). It derives the master key from the passphrase provided and then uses that to decrypt or encrypt the sectors of the device, with a direct 1:1 mapping between encrypted and decrypted sectors.

  • The primary advantage of using the plain format over LUKS is that there is no metadata at the beginning of the device. This means plain format has a higher resilience to damage as there's no single point of failure in the form of vulnerable header information. This also means that a plain format device cannot be proven to contain encrypted data, assuming an overwrite with crypto-grade randomness (e.g. from /dev/urandom) was done prior to the initial device creation.

  • The most obvious disadvantage is that you do not get all the nice features that the LUKS metadata offers, like multiple passphrases (which can be changed/removed/re-added), the cipher & cipher mode being stored in the metadata, anti-forensic properties like key-slot diffusion and salts, etc etc. However, there's a more sinister disadvantage: unlike with LUKS, plain dm-crypt derives a key directly from the password chosen -- this means that choosing a high-entropy (cryptographically-strong) passphrase is all the more important when using cryptsetup in this mode.

• LUKS

  • The LUKS format uses a metadata header and 8 key-slot areas at the the beginning of the device. The passphrases stored in these key-slots are used to decrypt a single master key that is stored in the anti-forensic stripes.

  • The advantages of LUKS over plain dm-crypt are the obvious higher usability: automatic configuration of non-default crypto parameters, the ability to add, change, and remove multiple passphrases. Additionally, LUKS offers defenses against low-entropy passphrases like salting and iterated PBKDF2 passphrase hashing. With LUKS, encryption keys are always generated by the kernel RNG; in contrast to plain dm-crypt where one can choose, e.g. a simple dictionary word and have an encryption key derived from that.

  • One disadvantage of using LUKS over plain is that it is readily obvious there is encrypted data on disk; the other is that damage to the header or key-slots usually results in permanent data-loss. See the Backup and Data Recovery heading in the LUKS FAQ for details on how to mitigate that risk.

Packages required for LUKS in Red Hat Enterprise Linux

• RHEL 4

  • The cryptsetup package in RHEL4 only supports plain dm-crypt volumes.

• RHEL 5, RHEL 6

  • The main package is called cryptsetup-luks and it depends on cryptsetup-luks-libs. Both of these packages should be part of any installation and therefore available without extra effort.

• RHEL 7

  • The main package is called cryptsetup and it depends on cryptsetup-libs. Both of these packages should be part of any installation and therefore available without extra effort.

Usage of LUKS in Red Hat Enterprise Linux

• The Red Hat Enterprise Linux installer (Anaconda) gives you choices in how to configure disk encryption. You can either let Anaconda configure full-disk encryption automatically (in which case it will use LUKS to encrypt the underlying LVM PV) or you can encrypt specific filesystems (in which case it will use LUKS to add encryption between the block device & filesystem layers -- e.g., by encrypting the LVM LV).

• Block devices can be encrypted after a system is installed by utilizing the cryptsetup command directly. Additionally, in the RHEL6 palimpsest / RHEL7 gnome-disks graphical disk utility can be used to accomplish the same. For more details on command-line usage of cryptsetup, run:

  • cryptsetup --help
  • man cryptsetup

• For links to various succinct how-to solutions, see:
  What is LUKS disk encryption and how can it be implemented?

On LUKS ciphers, cipher modes, IVs, and key sizes

• When creating a new LUKS-encrypted volume, there are basically 4 "knobs" that can be tweaked.

  • symmetric encryption cipher
  • cipher block mode
  • IV (initial vector) for the cipher block mode
  • encryption key size

• Note that cryptsetup and the Anaconda installer have their own safe & sane defaults. It is not necessary to explicitly tweak the above settings when creating a new encrypted volume -- indeed, unless you know what you're doing, it's actually discouraged. That said...

• The default mode used for LUKS when running cryptsetup luksFormat or when using the palimpsest graphical disk utility is "aes-cbc-essiv:sha256" with a key size of 256 bits.¹

• Anaconda (the RHEL installer) on the other hand uses the more efficient "aes-xts-plain64" mode when doing its luksFormat operations.² The default key size for this mode is 512 bits; however, due to the way AES-XTS works--splitting the key in half--this basically equates to AES-256 with some extra trickery.

• While changing the default encryption cipher cannot be recommended, it is an option and here are some of the choices:

  • AES - Advanced Encryption Standard - FIPS PUB 197
  • Twofish
  • Serpent
  • cast5 - RFC 2144
  • cast6 - RFC 2612

References

• Footnote ¹: See the cryptsetup FAQ, question "5.14 Why was the default aes-cbc-plain replaced with aes-cbc-essiv?"

• Footnote ²: See the cryptsetup FAQ, question "5.16 What about XTS mode?"

  • In short, the "aes-xts-plain64" mode is generally recommended over "aes-cbc-essiv" and is planned to replace it as the new default in cryptsetup. Additionally, "aes-xts-essiv:sha256" is also an option (albeit a less-efficient one); however, it is currently unknown whether it truly offers more security than "aes-xts-plain64".

• RHEL7 Security Guide, Section 4.10.1. Using LUKS Disk Encryption

  • There is also the older RHEL6 Security Guide, Chapter 3. Encryption

• RHEL6 Installation Guide, Appendix C. Disk Encryption

  • Note that this appendix is presented as multiple separate pages in the html version. For ease of perusal, consider downloading the large html-single version and finding Appendix C in the table of contents.

• dm-crypt page in cryptsetup wiki

• Frequently Asked Questions page in cryptsetup wiki