cross-posted from: https://programming.dev/post/19007507

For context:
I’ve encrypted the swap partition with:

cryptsetup -v luksFormat /dev/${DEVICE}
cryptsetup luksOpen /dev/${DEVICE} swap

And what I want is for the user to be able to enter their password only once to decrypt their root partition which would contain a keyfile to then decrypt their swap partition.

Does anyone know if this is possible?
Just thought I’d ask to see if anyone’s done this already

Links:

  • Ooops@feddit.org
    5·
    11 days ago

    This would -at least as far as I understand it- limit your swap’s functionality for hibernation etc. Because there your swap needs to be available early. You can still do it in theory, but the key file then would need to be included in you initrams, which kind of defeats the purpose.

    There is however a much more easier option: either use LVM on luks (so the volume is decrypted with the password and then contains both, root and swap) or just use the same password for root and swap while switching over to the systemd hooks (as those encryption hooks try unlokcing everything with the first provided password by default, and only ask for additional password if this fails).

    EDIT: Seeing that you crossposted this from an archlinux-specific community: You can find the guide here. It’s for using a fully enrcypted system with grub as bootloader, but the details (in 8.3 and 8.4) are true for all boot methods. Replace the busybox hooks with their systemd equivalents (in minitcpio.conf for archlinux but again this isn’t limited to that init system), then add “rd.luks.name=<your swap’s uuid=swap” to your kernel parameters and also replace the “cryptdevice=UUID=<your root’s uuid>:root” that should already be there for an encrypted system (that’s the syntax for the busybox hook) with “rd.luks.name=<your root’s uuid>=root”. On startup you will be asked for your password as usual, but then both root and swap will be decrypted with it (PS: the sd-encrypt hook only tries this once… so if you screw up and misstype your password on the first try, you will then have to type it again two times, once for root, once for swap…)

    • recursive_recursion [they/them]@programming.devOPEnglish
      2·
      11 days ago

      I’ve seen people do a similar thing with a separate encrypted home partition which is decrypted by a key stored in your encrypted root.

      Do you happen to have a link to this?

      However, I’d strongly recommend you use an LVM on LUKS setup (this is what I do). That way you decrypt one partition and you don’t have to mess around with keyfiles. #LVM_on_LUKS

      Looking at the wiki it seems doable (in relation to revising my script) and as far as I can tell the tradeoffs seems better than #LUKS on a partition

      much appreciated for the recommendation!

      • Ooops@feddit.org
        1·
        11 days ago

        There is a difference here.

        Unlocking home later in the boot process is not a problem, so the you can indeed have a keyfile on your root and get your home unlocked and mounted after root is done.

        Swap however needs to be available early, at least if you want to use it for hibernation.

  • Klaymore@sh.itjust.works
    2·
    11 days ago

    I have home and root partitions encrypted with LUKS, and since they use the same password it automatically unlocks both of them. I think it tries using the first successful password to unlock the other partitions.

  • CMahaff@lemmy.worldEnglish
    2·
    11 days ago

    Doubling what Klaymore said, I’ve seen this “just work” as long as all partitions have the same password, no key files necessary.

    That said, if you needed to use a key file for some reason, that should work too, especially if your root directory is one big partition. Keep in mind too that the luks commands for creating a password-based encrypted partition vs a keyfile-based encrypted partition are different, so you can’t, for example, put your plaintext password into a file and expect that to unlock a LUKS partition that was setup with a password.

    But the kernel should be trying to mount your root partition first at boot time where it will prompt for the password. After that it would look to any /etc/crypttab entries for information about unlocking the other partitions. In that file you can provide a path to your key file, and as long as it’s on the same partition as the crypttab it should be able to unlock any other partitions you have at boot time.

    It is also possible, as one of your links shows, to automatically unlock even the root partition by putting a key file and custom /etc/crypttab into your initramfs (first thing mounted at boot time), but it’s not secure to do so since the initramfs isn’t (and can’t be) encrypted - it’s kind of the digital equivalent of hiding the house key under the door mat.