Migrating from whirlpool hash for LUKS partitions

From Alpine Linux
Revision as of 08:10, 2 December 2022 by Mmhiro (talk | contribs) (Created page with "{{Draft}} See: https://gitlab.alpinelinux.org/alpine/aports/-/issues/13004 OpenSSL 3.0 has desginated the whirlpool hash as [https://wiki.openssl.org/index.php/OpenSSL_3.0#Provider_implemented_digests legacy]. This means it may not be loaded by default by OpenSSL so you cannot decrypt partitions using whirlpool. This is an issue for Alpine users because since v3.17 OpenSSL 3.0 is default, and multiple articles on this wiki recommended the use of whirlpool. In some case...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
This material is work-in-progress ...

Do not follow instructions here until this notice is removed.
(Last edited by Mmhiro on 2 Dec 2022.)

See: https://gitlab.alpinelinux.org/alpine/aports/-/issues/13004

OpenSSL 3.0 has desginated the whirlpool hash as legacy. This means it may not be loaded by default by OpenSSL so you cannot decrypt partitions using whirlpool. This is an issue for Alpine users because since v3.17 OpenSSL 3.0 is default, and multiple articles on this wiki recommended the use of whirlpool. In some cases (i.e. with an encrypted boot partition) a user may not be able to boot their system at all.

Migrate Away from Whirlpool

This has been tested on a LUKS1 partition. I am not responsible if you lose all your data.

If you suffer a power failure, kernel panic, or any interruption during the reencryption step, your data may be permanently lost.

First, get a LiveCD with cryptsetup (I used Fedora 37). Older versions of cryptsetup require cryptsetup-reencrypt to modify LUKS1 partitions, while newer versions (2.5.0 or 2.6.0 or later) use cryptsetup reencrypt.

Then backup your drive. At the minimum, dump the headers using

cryptsetup --header-backup-file=backup_file_location.bin luksHeaderBackup /dev/partition

You should store the header on a USB stick or some other form of persistent media.

If you have keys that cannot be typed in (i.e. keyfiles) then you will have to either

  1. find one key that you want to preserve (you must know the keyslot, in this document it will be called N)
  2. or remove all keyfiles using luksRemoveKey

I removed my keyfile slot using luksRemoveKey and then confirmed that my password still worked using cryptsetup luksOpen --test-passphrase /dev/partition. If you mess up, you can try recovering your keys using luksHeaderRestore.

Make sure that the device is not opened (if you had to get files off of it, run cryptsetup luksClose device_name). If you are preserving keyslot N, run

cryptsetup reencrypt --keep-key --key-slot N --key-file keyfile.bin --hash sha512 /dev/partition

If you are not specifying a keyfile, run

cryptsetup reencrypt --keep-key --key-slot N --hash sha512 /dev/partition

and enter all passwords into the prompts. You can specify another hash if you want to, but sha512 is probably your best choice right now.

Once the command is done (should take a few seconds), verify that you can successfully open and mount your partition.

If you use an encrypted boot, then you must also reinstall grub. Open your partition with cryptsetup and mount it. Enter the directory and run

mount -t proc /proc proc/
mount -t sysfs /sys sys/
mount --rbind /dev dev/
chroot . /bin/ash

Then run grub-install. The command line will differ depending on your setup (EFI vs. MBR). On MBR run

 grub-install /dev/sdX