While I’m trying to get Encrypted /boot and a detached LUKS header on USB to work,
I had a couple of questions come to mind:

1. Does the backup USB key need to be updated?
2. If so, then how would someone keep all backups up to date?

I probably asked a dumb question but if anyone can help guide me through the steps I’d really appreciate you!🤗🌻

  • John Richard@lemmy.world
    link
    fedilink
    English
    arrow-up
    3
    ·
    1 month ago

    What do you mean need to be updated? You store the LUKS header in an IMG file on the USB drive. I ran this setup for many years. It is kind of difficult to mess up, but you should keep at least one offline backup. Last thing you want is to lose your ability to decrypt your data.

    • recursive_recursion they/themOPM
      link
      fedilink
      English
      arrow-up
      2
      ·
      edit-2
      1 month ago

      oh actually thinking about it again, the only thing that’s stored on the USB is the keyfile right?

      Sorry I’m still a bit confused after trying to follow alongside the arch guide

      • John Richard@lemmy.world
        link
        fedilink
        English
        arrow-up
        2
        ·
        1 month ago

        Well technically it is the header but yeah that is what is stored there. There are times you might want to change the encryption and what not so I guess the header could get changed or you could add a key, but regardless you’ll know what needs to happen cause it ain’t going to happen otherwise. I only had two issues during my time of a detached header.

        One was that something changed with mkinitcpio. Can’t remember if it was my fault partially too or not, but basically had to add back exfat support to the initramfs since that is what I had formatted the USB drive as to access my key file. The second time was an update with systemd that caused a change with how the systemd-boot module loaded the drive.

        The important thing is to get familiar with booting into a recovery image (basically the Arch Installer) and using the header flag with cryptsetup and `cryptsetup open --header’ I believe followed by your header file and the encrypted drive/partition. After that is is just a matter of mounting the decrypted device mapper partition. You should only need to do this if you have issues but once I figured out how it saved me a lot of anxiety.

        • recursive_recursion they/themOPM
          link
          fedilink
          English
          arrow-up
          2
          ·
          edit-2
          1 month ago

          ahhh ok I’m starting to understand now thank you!

          Also for the exfat problem you encountered, I’ve read that the boot or EFI partition should be formatted with FAT32 or the similar FAT types (like FAT12?) as it’s supported whereas the other file types are not mentioned, I’ll add the link here if I can find it again

          https://bbs.archlinux.org/viewtopic.php?id=236633
          While this forum post wasn’t the exact page I initially saw, the users there also states the same info

          • John Richard@lemmy.world
            link
            fedilink
            English
            arrow-up
            2
            ·
            edit-2
            1 month ago

            Yes that is true, but if you’re using a detached LUKS (prob LUKS2) header then the USB drive isn’t your boot partition and the file system type won’t matter as much for that than the order of kernel modules loaded before boot.

            Using a detached LUKS header appealed to me at the time because it has most of the same benefits as an encrypted boot partition like available with GRUB and GRUB at the time still only supported the first version of LUKS. Plus I was pretty confident in my ability to securely back up my LUKS header, so that if I traveled then I could grab a copy of the header remotely if the USB drive was somehow compromised. That way you can travel and not have to worry about your laptop or whatever revealing as much information about your FDE setup vs. if the LUKS header is on the internal drive, it still provides details about the encryption.