Talking about encryption in the previous post, I realized there are a few details I keep having to look up. This is a collection of the Frequently Asked Questions about cryptsetup formatting and mounting.

Note: For all the following examples, the example device /dev/sdX is used. It's a device and file which doesn't exist, on purpose. When replacing with your own e.g. /dev/sda or similar, be careful!

Formatting a new physical drive

Before working with a new drive, it's recommended to check for bad blocks, to confirm it's not a DOA (Dead on Arrival). If it is, you might want to claim it on the warranty immediately to avoid losing data in the future.

This command will check for bad blocks, as well as fill the disk with random data to better hide the encrypted volume later:

badblocks -c 10240 -s -w -t random -v /dev/sdX

Next is the partition setup, where all you need is a new cleared (similar to unformatted, but actually cleared) partition. In the gparted UI it's simply "New -> Cleared -> Apply", while on the CLI it would go something like this, to create an optimally aligned, primary partition.

parted /dev/sdX mklabel gpt
parted -a optimal /dev/sdX mkpart primary '0%' '100%'

Now, coming to the encrypted volume, you could just use a passphrase, and skip the first line, or store a salted hashed password in a key-file. The benefit of the latter, is that it will generally be a more secure key, and yet you could re-created the keyfile if you lost it, assuming you remember both the password and the salt.

mkpasswd --m=sha-256 --salt='SOME_SALT' | tr -d '\n' > /tmp/key-file

cryptsetup luksFormat /dev/sdX1 /tmp/key-file
cryptsetup open /dev/sdX1 unenc --key-file /tmp/key-file

Notice the mapping name "unenc", which can be anything of your choosing.

Finally, format and mount the drive. Here, the ext4 file-system is used, with 1% reserved for system

mkfs.ext4 -m 1 -O dir_index,filetype /dev/mapper/unenc
mount /dev/mapper/unenc /mnt/tmp

Creating an encrypted file volume

In some cases, it is useful to encrypt only a small part of the disk, or even move the encrypted container around. A loop device can create a filesystem inside a file residing on any file system, be it USB stick, network mount or local disk.

First, you will have to create an empty file. The dd command will copy zeros to the specified filename. The total size is block size times count, or 500 MB in this example:

dd if=/dev/zero of=myfile bs=1M count=500

Then establish the loopback. It will become available on /dev/loop0, and can be formatted and mounted like any other block device.

losetup /dev/loop0 mycryptfile

Now repeat the luksFormat and filesystem format commands from above:

cryptsetup luksFormat /dev/loop0
cryptsetup open /dev/loop0 mycrypt
mkfs.ext4 -m 1 /dev/mapper/mycrypt
mount /dev/mapper/mycrypt /mnt/tmp

Key managment

Most of the cryptsetup commands above have at least two options when dealing with the keyslot: A passphrase and a key file. Typically, a passphrase is typed in on the prompt when unlocking the partition or modifying the other keys, while a key file is supplied using the --key-file argument. In terms of security, the first is "something you know", while the latter is "something you have".

To list the active keyslots use the following command. It will work both on an open and closed partition.

cryptsetup luksDump /dev/sdX

To add a new key with a prompted password:

cryptsetup luksAddKey /dev/sdX

or a randomly generated key-file:
dd bs=512 count=4 if=/dev/urandom of=~/keyfile_for_sdX iflag=fullblock

cryptsetup luksAddKey /dev/sdX ~/keyfile_for_sdX

To erease one of the existing key-slots, assuming you have more than one.

cryptsetup luksKillSlot /dev/sdX <key slot number>

You might also want to backup the LUKS header, which includes the key-slots, so in case you overwrite existing keys, you can restore the header and unlock with the old keys. It should be noted, that this header will then be able to unlock the partition given any password or keyfile in its keyslots. So, even if you change a password, the old header can be restored and an old password used to unlock. Therefore, it should be considered a secret file and stored securely just as the key file.

cryptsetup luksHeaderBackup /dev/sdX --header-backup-file ~/header_for_sdX

Finally, you might need to wipe the whole encrypted volume. You can do this with the luksKillSlot command, or manually remove all keys, and then change or add the remaining one with a password or keyfile you later remove or forget. E.g. by generating a key-file on the RAM disk /dev/shm, and then rebooting to lose it.