Fedora – Formatting LUKS encrypted disk

Your approach looks good. Some remarks though:

• If you want to encrypt rootfs, you'll need to use initrd (to have some minimal unencrypted system that will process the encrypted partitions).

  If the USB device is removable, both initrd and kernel can be stored on the USB to heighten tamper resistance (supposing you make sure the USB won't get into unauthorized hands) - which is usually why one encrypts rootfs. Once both kernel and initrd are on a removable media, you can ensure that nobody changes the kernel (or initrd) from the running system by simply removing the media.

  This is of course not an option if you want to have it inside of a server, but then again the question stands whether it makes sense to have such a device at all and not to use a small partition on one of the hard-drives. If for example all drives in the machine are in RAID, one would probably want to put rootfs on the USB as well. An interesting alternative to an internally connected USB flash device could be a CompactFlash card attached to ATA interface through an adapter, by the way.

  Some distributions offer prepared solutions for encrypted root, some don't - but mostly it's question of putting a couple of lines into initrd script before it tries to mount the "real" root (see for example man pages for pivot_root, usually in sections 2 (syscall) and 8 (bonary), if you're not familiar with the process).

• remember to backup the keys and passphrases in case your USB drive dies. LUKS follows rather one-sided approach when it comes to damaging its header - once a single sector of its header (key-slot to be more precise) dies, you are unable to mount it. This is to make sure that erasing the header isn't effectively thwarted by block reallocation performed by the device itself (because that's what flash-memory based devices do a lot) - the key is spread over the whole key slot and one needs all of the data to reconstruct it - there is no redundancy. See Clemens Fruwirth's website for deeper discussion.

  That said, maybe a simple encrypted device on the USB would be enough (check section PLAIN MODE in man cryptsetup). Or a file encrypted with e.g. openssl enc. The former might actually be an option even for the encrypted partitions themselves.

Depends on what the init script that asks the password of you is doing with it.

If it's systemd, it might just be a feature. systemd-ask-password comes with a cache functionality that might be responsible.

https://www.freedesktop.org/software/systemd/man/systemd-ask-password.html

--accept-cached

    If passed, accept cached passwords, i.e. passwords previously entered.

--multiple

    When used in conjunction with --accept-cached accept multiple passwords.
    This will output one password per line.

In this fashion it would first try the passwords you already entered, and only ask for another passwords if that didn't work.

The downside of such an idea is that checking a password takes 1 second of CPU time with LUKS, so if you had a lot of LUKS containers, these attempts might slow you down. But most people have only one or two and it's actually not uncommon for them to use the same passphrase.

I actually couldn't locate the source code specifically responsible for this, so the above is only conjecture and I have no idea if this is a feature you could choose to disable somehow.

Found what seems to be the responsible code, see it here on Github.

There's a for loop that starts with tries = 0 and increments tries by one each iteration.

This loop calls get_password() with bool accept_cached set to true if tries == 0 && !arg_verify. So if there are already passwords cached in the first iteration of the loop, it will just return the cached passwords. If those don't work, next iteration with tries == 1 sets accept_cached to false and only then it will ask you to provide another passphrase to try with.

The list of passwords is passed on to attach_luks_or_plain(). This will be the previously cached password(s) in the first iteration, and the single new password in all following ones, so it won't re-try previously tried passwords (unless perhaps if you keep typing in the same one).

As for keeping passwords plaintext in memory, the list of passwords is declared as a _cleanup_strv_free_erase_ char **passwords = NULL; so that at least makes it sounds like cleanup will be taken care of properly at some point.

Keys are always in memory somewhere, that much can't be helped, crypt needs masterkey to work, as long as the container is open, you can always see it with dmsetup table --showkeys.

It seems like you normally have arg_tries = 3 three attempts to enter a working passphrase, but if you have multiple containers and the cached passwords didn't work, it will only give you two tries to enter the passphrase, since the cached password attempt already counts as the first try. I have no encrypted systemd machine to test if this is true or I'm just misreading the code somewhere.