Dm-crypt full disk encryption

This article aims to get started with DM-Crypt LUKS to be able to install a new system from scratch, using Gentoo installation documents for example, and generate an initramfs with that in no time. So this article will skip right away the premises on why to encrypt a system with DM-Crypt LUKS and on security insights. That said, encrypting a system with DM-Crypt LUKS will immediately put you in a position to choose between security versus usability, and secure versus system speed/responsiveness.

Which key (file) mode?
Choosing a key or key file mode depends on the secure requirements of the system: a long and random password with special characters is more secure than an easy dictionary breakable password of course. So to meet the length, randomness and complexity of password requirements a key file seems to be the right spot. However, a key file dose not meet the security/secure requirements side because it is always better to leave no traces behind which could compromise or ease the break ability of an encrypted system or disk. This is where GnuPG crypted key files comes into play which will satisfy almost every aspect with a little minus in security because the key file can be accessible from world.

GnuPG crypted key file
To get a secure key file that could be piped to cryptsetup, one could generate a random key from `/dev/random' and encrypt it with GnuPG. Or else, a simple password will be sufficient if there are not severe secure/security requirements.

Or to get maximum (528 bits) entropy use the following instead (to get 88 characters).

LUKS crypted key file
To get a simple and secure crypted key file, one could use DM-Crypt LUKS to generate one via loop back device to avoid having an extra binary to deal with, if size and such are limiting factors for an initramfs for example.

That's all, now one can use that secure crypted key file to decrypt cyphertext.

Which cipher:hash combination?
I will spare you a cryptographic cipher:hash discussion. Though there is a simple paradigm on secure versus speed for a cipher: secure cipher are usually slow and require more computing cycles. A few benchmarks can be found out there: cipher benchmark for DM-Crypt LUKS. AES is the fastest cipher out there, especially if used in ECB (electronic code book) mode (-c aes-ecb-plain[|benbi|null]) with key size of 128 bits (-s 128), which is widely used. blowfish cipher is just behind, twofish is relatively slower than AES and serpent is the slowest in the cipher set. serpent and twofish is considered to be more secure than AES.

Following the breakage of previous SHA-0 and SHA-1, SHA-2 (SHA-256/224, SHA-512/384) is considered to be secure enough to be used in governmental agencies. Whirlpool, based on AES and its source is open and the authors declared it will remain open, is considered to be more secure than SHA-2. There are other cipher:hash like the RIPEMD family and others: checkout the cipher:hash supported by your kernel by looking at `cat /proc/crypto'.

At this point, you should have decided `-c ... -s ...' argument that will be used to encrypt physical device(s) or partition(s) or cyphertext in DM-Crypt LUKS terms.

Preparing the disk(s)
Lets prepare the disk(s) is the only thing that deviate from the official installation documents along with generating an initramfs.

With the previous section, remains encrypting the physical devices. Before doing just that, one should consider the order of DM stack depending of using RAID, LVM or a modern file system that include both in the file system layer like ZFS.

Using RAID and/or LVM together make it easier to only encrypt the resulting logical volume especially for RAID. If using LVM with fewer logical volume than the number of physical volume, it makes sense to crypt the logical volume. There's no practical advantages to use LUKS on the underlaying volumes of RAID arrays but to raise the complexity while lowing usability.

With a modern file system like ZFS, there's not choice but encrypt the physical volume or vdev in ZFS terms.

Before encrypting the devices, considering the `/boot' partition should be taken into account as many bootloader does not support LUKS. GRUB2 should support LUKS formated devices although I did not try to load kernel+initramfs yet. So some spare space should be allocated for `/boot' if necessary.

GRUB2 also support ZFS so in that case, one could encrypt with '--align-payload 0 --header /dev/|/path/to/file', the whole disk, to set up a more secure setup and be able to claim the "plausible deniability" because nothing in the disk can prove that the disk is encrypted. This, however, require >=sys-fs/cryptsetup-1.4.0.

GnuPG crypted key file should be piped to cryptsetup with something like `gpg -qd /path/to/key |' while LUKS crypted key file via loop back device is given like a regular key file (/dev/mapper/key.lbd) after decryption.

When done, creating logical volume if using LVM or adding the crypted cyphertext to a vdev can be done then.

Generating an initramfs
After encrypting system or disk(s), one will need an initramfs so that rootfs can be mounted in there and then pass the control to real init. There are a few generic initramfs builder that can be used to accomplish the task such as dracut, mkinitcpio (there's an ebuild ad thread in the forums) sys-boot/mkinitramfs-ll or even sys-kernel/genkernel[cryptsetup] which has LUKS support.

Now, with a complicated setup one could have to build his/her own to satisfy specific requirements. This where modular or advanced initramfs package shine such as mkinitramfs-ll dracut or mkinitcpio.

The following is a simple script that will build an initramfs with LUKS support for the running kernel or for the kernel version passed as argument 1.

And the following is a simple init script which will mount rootfs in initramfs environment. The following script and the previous are adapted from mkinitramfs-ll.

See mkintramfs-ll/init for a fully featured init script.

External resources

 * DM-Crypt with LUKS community wiki article