Does crypttab's "key-slot" option mean LUKS will try that keyslot "only", or "first"?

Question

I am following the Debian dev's guide to full disk encryption. I am currently on Section 4, step 3- editing /etc/crypttab.

In the guide, in section 3 they set up keyslot 0 for something else and now in section 4 are setting up keyslot 1.

However, during my setup, section 3 defaulted to keyslot 1, and therefore for section 4 I will need to use keyslot 0, by adding this to my /etc/crypttab:

root_crypt UUID=... /etc/keys/root.key luks,discard,key-slot=0 (the guide has key-slot=1 here instead)

I think. I worry that I may be wrong, put key-slot=0 when I should have put key-slot=1, so LUKS looks at the wrong slot for decryption, fails to decrypt due to wrong password, and cannot continue. And since everything's encrypted, I can't fix it with a live OS.

So my question is: Does the key-slot= option makes LUKS only try that keyslot, or try that keyslot first and if it fails try the other ones? Assuming I am wrong and put key-slot=0 when I should have put key-slot=1, will LUKS try slot 0, fail, then try slot 1, and succeed?

I've read through /etc/crypttab's manpage and found nothing but a reference to cryptsetup -S, but cannot find the manpage that describes this option. I can only find one page on cryptsetup, which doesn't include the -S option.

Thank you very much!

Answer 1

Does the key-slot= option makes LUKS only try that keyslot

Yes, usually that is the case.

It's equivalent to the --key-slot option, man cryptsetup-open:

--key-slot, -S <0-N>
This option selects a specific key-slot to compare the passphrase against. If the given passphrase would only match a different key-slot, the operation fails.

This is meant to be a performance optimization. When using many keyslots, it takes quite long to check every single one.

Additionally, LUKS 2 also allows setting keyslot priorities (normal,prefer,ignore) via cryptsetup config --priority. This then behaves more like you described, it will try the prefer keyslots first, then the normal ones.

And since everything's encrypted, I can't fix it with a live OS.

Why don't you decrypt it in the Live / Rescue environment?

Alternatively you could add / change the passphrase for the expected key slot, so you wouldn't have to mount / chroot the decrypted system at all.

Answer 2

The cryptsetup manual is divided into several pages. The crypttab man page should reference the cryptsetup-open man page.

--key-slot, -S <0-N>

This option selects a specific key-slot to compare the passphrase against. If the given passphrase would only match a different key-slot, the operation fails.

So you'll have to correct or remove the key-slot option in /etc/crypttab.

Note that by default, all slots are tried, so the only advantage of specifying a key slot explicitly is a speed improvement.

You can recover from a live USB (I think the Debian netinst image has the necessary tooling, but I haven't tried this recently). The file you need isn't encrypted, since it's needed to decrypt the rest of the system. You should be able to fix your system from the initramfs as well (don't you get a shell prompt?), by running cryptsetup, mount and any other necessary step manually until you gain access to the root filesystem.