Someone posted a link in the fediverse to this piece, “PSA: upgrade your LUKS key derivation function”.

Although I’m sceptical that, in the situation mentioned - the “French anarchist” - the most likely answer was that his LUKS partition was brute-forced, the advice about improving the LUKS key derivation function seemed sensible, and beneficial, without particular risk.

I use Debian’s stock “encrypted LVM” installation option. (Officially, in the installer, it is “Guided - use entire disk and set up encrypted LVM”.) This gives me encrypted storage, via LUKS, but with an unencrypted /boot partition.

Because /boot is unencrypted it is perhaps the most vulnerable bit of the system, but it also makes updating the key derivation function for the crypt storage much easier.

The essence of what I did (just in case the linked blogpost, which has the full explanation, vanishes) is:

lsblk

Which revealed

[a load of snap loops]
nvme0n1             259:0    0 476.9G  0 disk  
├─nvme0n1p1         259:1    0   512M  0 part  /boot/efi
├─nvme0n1p2         259:2    0   488M  0 part  /boot
└─nvme0n1p3         259:3    0   476G  0 part  
  └─nvme0n1p3_crypt 254:0    0 475.9G  0 crypt 
    ├─x1--vg-root   254:1    0 474.9G  0 lvm   /
    └─x1--vg-swap_1 254:2    0   976M  0 lvm   [SWAP]

This showed that the device I needed to modify was /dev/nvme0n1p3.

I backed up the LUKS header:

sudo cryptsetup luksHeaderBackup /dev/nvme0n1p3 --header-backup-file /tmp/luksheader

(except I backed it up straight to an encrypted memory stick instead of /tmp.)

I didn’t need it but, if I did, the command to restore it would be sudo cryptsetup luksHeaderRestore /dev/whatever --header-backup-file luksheader from a live distro.

I then looked for what version of LUKS I had, with:

sudo cryptsetup luksDump /dev/nvme0n1p3

and I got:

LUKS header information
Version:       	2

So I did not need to update the header.

I looked at the same output, for PBKDF.

It was:

PBKDF:      argon2i

i, not id.

So I updated it with:

sudo cryptsetup luksConvertKey /dev/nvme0n1p3 --pbkdf argon2id

It asked for my LUKS passcode, and that was it.

Now, the output of sudo cryptsetup luksDump /dev/nvme0n1p3 was:

PBKDF:      argon2id

I rebooted, and it worked, so all good.

Why bother?

1. It looks like this can only be positive. There are no obvious unwanted side effects.

2. Once I’d read the blogpost linked above, I was aware that my current setup might be less secure than I had previously anticipated. And, since the fix was trivial and unintrusive, I had little justification for not doing it, in terms of “appropriate technical and organisational security measures” to protect the data on my device.

3. I’d rather not have to explain to a regulator, in the event that I lost my laptop, that perhaps the security was not as good as it might have been. It could be the difference between the existence of a personal data breach under the UK GDPR, and there being no personal data breach.