New installation with full disk encryption creates weird results

General system Bug reports
1

Hello,
I’ve installed Endeavor last week, and enabled full disk encryption. Everything worked fine, except for a weird thing where after the installation was completed and first boot was initializing, cryptsetup (I believe) hung on executing some post-installation script and the PC needed to be rebooted. Everything worked fine afterwards though, so I don’t know if this needs to be reported, especially since I don’t have logs.

However, today, I found out that the LUKS headers generated were quite strange. First of all, they were both (main and swap partition) version 1, which seems weird to me, since most distros - to my knowledge - already moved on to LUKS2 by default. Okay, no problem, I’ll just update them myself, although it should probably be changed by default, IMO.

Now, the weirder thing: Both partitions had two keyslots generated. Only one was the actual keyslot unlockable with the passphrase, while the second was something completely random. The key derivation function on it couldn’t be changed, cryptsetup wouldn’t unlock it (unlocking keyslot 1 only unlocked keyslot 0, for some reason?), and running cryptsetup luksRemoveKey with the correct passphrase would only remove keyslot 0, keeping keyslot 1, and subsequent tries to remove it with the passphrase just threw errors about there not being any keyslots with specified phrase. In the end I had to use luksKillSlot on it for each partition.

Now, I’m not too well versed in Linux encryption, but this seems like something that shouldn’t happen? I haven’t touched cryptsetup or anything else before today, so the keyslot definitely wasn’t created by me. The only things I can think of was either the post-install script doing something weird when it hung, or a bug in the default configuration. I’m not sure if I can help beyond what I wrote, since all the header upgrade had to oblviously be done in a live enviroment, so I don’t have any logs saves, but if I can, let me know.

2

Most distros are still using luks1 because grub doesn’t support luks2 with argon2id.

That is normal if you are using grub. The first keyslot is your passphrase. The second keyslot is a keyfile.

If you didn’t have that, you would get asked for your password multiple times. Grub would unlock it but then the intrd would get a hold of it and ask for your passphrase to again. Then it would need your passphrase a 3rd time to unlock swap.

To avoid all that, a keyfile is added to each luks volume. The keyfile is stored inside the encrypted root volume. That way, grub decrypts the root volume using your passphrase and then the initrd uses the keyfile to do any further decryption.

2 Likes
3

Most distros are still using luks1 because grub doesn’t support luks2 with argon2id.

I was assuming that since Arch is using LUKS2, you’d too. IIRC, most “big” distros already moved? I know Debian, Arch, Fedora, Mint, Ubuntu and POP are all using LUKS2 now.

That is normal if you are using grub. The first keyslot is your passphrase. The second keyslot is a keyfile.

I’m using systemd-boot, which is why it’s weird to me…

4

If @dalto doesn’t teach me a better result…
As far as i remember it is a limitation on providing both on the installer Grub and Systemd-boot if it was only systemd-boot we could provide LUKS2 but as long as we do support grub for legacy and efi installs we are limited to use LUKS1 without doing some huge modifications to the code…-

5

I don’t know about mint but debian, ubuntu and fedora all use an unencrypted /boot with grub. That lets them not have to worry about what encryption grub supports.

However, we retain grub support for two primary use cases:

  • Those who want to boot off btrfs snapshots
  • People who prefer their kernel and boot images encrypted

In both those use cases, an unencrypted /boot will not work. Because of this, we need to retain luks1 support for grub.

We are looking into using luks2 when systemd-boot is selected in a future release but have not progressed far enough yet to commit to it one way or the other.

When we released Cassini, the Calamares installer we use didn’t support luks2.

2 Likes
6

this is exactly why I use LUKS1 and I’m glad that EOS has support for GRUB in the installer.