Abstract

Applying good disk encryption is a great way to protect data at rest. This is important in a variety of contexts; whether it be a journalist protecting a source’s story, a company protecting company assets, or just a person protecting their right to privacy. Good disk encryption can provide a layer of protection in all of these situations, but how does one go about setting up disk encryption on Linux? The standardized method of doing this is by using LUKS and cryptsetup

What is LUKS and Cryptsetup?

Some Notes Before Getting Started

Cryptography is a very difficult field that requires a lot of study and mathematics. Cryptsetup allows users to handle their own encryption via the dm-crypt kernel module, however, this is specifically pointed out in the cryptsetup man page, as well as in the FAQ:

Unless you understand the cryptographic background well, use LUKS. With plain dm-crypt there are a number of possible user errors that massively decrease security. While LUKS cannot fix them all, it can lessen the impact for many of them.

Effectively, if you aren’t sure that you understand cryptography, don’t use plain dm-crypt and expect it to be secure. You will most likely do it wrong and leave your disks vulnerable to avoidable attacks.

This blog post will only cover using LUKS as I do not have enough background in cryptography to even begin to explain how to properly use plain dm-crypt.

Examples

The commands for encrypting a disk (or really any block device) are not particularly difficult.

Encrypting a disk

The following commands show how to encrypt a disk located at /dev/sda, then create a file system and mount it at /mnt:

# Run as root

# Format the entire drive with LUKS1 encryption
cryptsetup luksFormat --type luks1 /dev/sda
# Open the encrypted block device
cryptsetup luksOpen /dev/sda drive
# Create a file system on the now decrypted device
mkfs.ext4 /dev/mapper/drive
# Mount the device
mount /dev/mapper/drive /mnt

It is worth noting, the drive that follows the /dev/sda is just a label and can be anything as long as there are not duplicate files in /dev/mapper (where cryptsetup maps decrypted devices). drive will be used for the remainder of this post, but know that it could be any other label.

Using a Key File

Additionally, a keyfile can be created to unlock the encrypted volume without having to type a password. NOTE, this command uses dd, which can and will happily overwrite anything that you point it at with no warnings. Before running the command, please make sure the syntax is correct, specifically the of location, as that is the location where the data will be written. Pro tip, if stands for ‘input file’ and of stands for ‘output file’.

# Run as root

# Create the keyfile with pseudo random data
dd bs=1 count=64 if=/dev/urandom of=${HOME}/keyfile
# Add the key to the current encrypted volume
cryptsetup luksAddKey /dev/sda ${HOME}/keyfile
# Then use this command to unlock the encrypted volume with the key
cryptsetup luksOpen /dev/sda drive --key-file ${HOME}/keyfile

Additionally, another passphrase can be added rather than a key by just removing the location of the keyfile:

# Run as root
cryptsetup luksAddKey /dev/sda

Changing the passphrase

At some point, changing or removing a key (either passphrase or a keyfile) may be required for one reason or another. This can be done by running the following command:

# Run as root

# This command is for changing a passphrase
cryptsetup luksChangeKey /dev/sda
# This command will replace an existing passphrase with a keyfile
cryptsetup luksChangeKey /dev/sda ${HOME}/keyfile

Cryptsetup will then ask the user to enter the passphrase that needs to be changed, then a new passphrase to replace it with. However, changing a keyfile, or replacing a keyfile with a passphrase is slightly less straightforward. The process would actually look more like removing the old keyfile and adding a new keyfile or passphrase to the encrypted volume:

# Run as root

# Removing old keyfile
cryptsetup luksRemoveKey /dev/sda ${HOME}/keyfile

Then add the new keyfile or passphrase as shown previously.

Backups

As most everyone should know in 2025, backups are important, and this is true even with encrypted data; but how does one backup encrypted data? That’s a good question, that has two basic answers.

Backup the entire encrypted disk: Basically, just dd the entire disk to another storage pool as the backup, if restoration is needed, just dd it back onto a disk and carry on. This has the benefit of the files staying encrypted, however, it is going to take a lot more space and doing differential backups is not really possible (at least to my knowledge).
Backup just the files on the encrypted disk. This has the benefit of keeping storage space for the backups to a minimum, but the encryption will have to be handled separately from the original files.

Once the preferred type of backup is chosen, the specifics are really just which tools are going to be used. There are many different backup tools for Linux and other systems that use cryptsetup, so I am not going to go in-depth on that.

Guides for Encrypted Root

An Linux install with full disk encryption is not very difficult to do. Quite a few distros with proper installers have the option for it, but some distros don’t. I am leaving two guides that should be useful in getting started. The basic idea is just to use cryptsetup to encrypt the disk, create your partitions and file systems, then install onto those file systems. Both the Arch wiki and the Void Linux docs page have guides on how to do this that are probably better than what I would produce.

Simple, right?

Sure, the commands are simple enough to follow, unfortunately the tricky bit with cryptography is understanding the reasons behind what you are doing. Why use LUKS1 over LUKS2? Which algorithms are secure? For those answers, I lean on people smarter than myself on the topic… the team that made cryptsetup. They have an FAQ page that answers most any question that you could dream up for the tool. Additionally, if you dream up a question that is not on that list, there is a mailing list that questions are welcomed at.

Tyler's Site