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 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:
[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
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
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
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:
I rebooted, and it worked, so all good.
It looks like this can only be positive. There are no obvious unwanted side effects.
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.
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.