Encrypt and re-encrypt LUKS without data loss

Introduction

If you have ever thought about encrypting data on disks already after you had accumulated a decent amount of them, you were probably upset by reading about the need to transfer data before creating an encrypted partition and after. Transferring 500 GB back and forth does not present any particular difficulty, such a volume can be temporarily downloaded even into the cloud, but if we are talking about encrypting 6 hard drives of 4 TB each, the task becomes much more complicated. For some reason, the ability to encrypt and re-encrypt LUKS volumes without data loss (in-place re-encryption) is poorly lit on the Internet, although there are two utilities for this: cryptsetup-reencrypt , part of cryptsetup since 2012, and third-party luksipc which appeared a year earlier. In fact, both utilities do the same thing — they encrypt a partition if it has not been encrypted, or re-encrypt an existing one with other parameters. For my needs I used the first official one.

How it works?

Suppose you have a typical disk layout: one partition, starts with 1 MiB (alignment for 4KiB sectors), ends at the end of the disk.


The LUKS header is located at the beginning, in front of the encrypted data. A header requires a minimum of 2056 512-byte sectors, i.e. slightly more than 1Mb. The space before the beginning of the partition is obviously not enough for us, so first you need to reduce the size of the file system from its end, so that cryptsetup-reencrypt transfers blocks to the right to the end of the disk, thus freeing up space at the beginning of the partition for the LUKS header. The final size of the header depends on the key length, the number of slots for passphrases and other parameters, so I recommend being careful and take 4 MiB under the heading.

')

Encrypt!

First, reduce the size of the file system. In the case of ext4, this is done as follows:

# e2fsck -f /dev/sdc1 e2fsck 1.42.12 (29-Aug-2014) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information SAMS15TB: 17086/536592 files (0.4% non-contiguous), 341465037/366284385 blocks # dumpe2fs /dev/sdc1|grep 'Block count' dumpe2fs 1.42.12 (29-Aug-2014) Block count: 366284385 # resize2fs /dev/sdc1 366283361 resize2fs 1.42.12 (29-Aug-2014) Resizing the filesystem on /dev/sdc1 to 366283361 (4k) blocks. The filesystem on /dev/sdc1 is now 366283361 (4k) blocks long. 

where 366283361 = 366284385-1024 (blocks of 4k), i.e. decrease by 4 MiB
It should be noted that this will not reduce the size of the partition itself, and it does not need to be reduced!

It makes sense to run the cryptsetup benchmark . Most likely, AES will be the fastest on your computer, since modern processors accelerate it in hardware. On my computer, serpent turned out to be the fastest algorithm.

Getting to the encryption process itself. Attention! According to the developers, cryptsetup-reencrypt is an experimental software, and can kill your data, so better backup.

 # cryptsetup-reencrypt -c serpent-xts-plain64 -s 256 -N --reduce-device-size 4M /dev/sdc1 WARNING: this is experimental code, it can completely break your data. Enter new passphrase: Progress: 0.0%, ETA 1107:23, 168 MiB written, speed 21.5 MiB/s … 

The -N tells you to create a LUKS partition, and the --reduce-device-size indicates an empty space after the file system.

The encryption process is not fast, you have to wait, it took me about 3 days for everything about everything. Make sure you start cryptsetup-reencrypt from the directory to which you have write access, so you can stop the encryption process via CTRL + C and continue it after if something went wrong.

After the encryption is completed, we connect the disk to the device mapper and mount it:

 # cryptsetup luksOpen /dev/sdc1 crypt # mount /dev/mapper/crypt /media/hdd 

That's all. We received an encrypted disk that did not require data transfer.