Edit: Turns out for what I’m trying to do (mount luks encrypted raid after start up) only needs the device mapping for the raid drive and not a file-system object.

So I luks encrypted the raid and call a script to open the vault and mount it when I need to.

In my system config file I added a raid drive like so:

(mapped-devices (list (mapped-device
                                     (source (uuid
                                                  "205e5caa-694f-4457-a2a1-8affa3536e75"))
                                     (target "guix")
                                     (type luks-device-mapping))

                                  (mapped-device
                                     (source (list "/dev/sdb1" "/dev/sdc1"))
                                     (target "/dev/md0")
                                     (type raid-device-mapping))))

(file-systems (cons* (file-system
                                  (mount-point "/")
                                  (device "/dev/mapper/guix")
                                  (type "ext4")
                                  (dependencies (list (list-ref mapped-devices 0))))

                               (file-system
                                  (mount-point "/mnt/nas")
                                  (device "/dev/md0")
                                  (type "ext4")
                                  (mount? #f)
                                  (dependencies (list (list-ref mapped-devices 1)))) %base-file-systems)))

I’d now like to luks encrypt the raid drive but I’m not sure how to go about doing it. Do I simply make a another mapped-device object, specifying the raid drive uuid and “/dev/md0” as the target:

(mapped-device
   (source (uuid
                {raid uuid}))
                (target "/dev/md0")
                (type luks-device-mapping))

and then pass that as a dependency to the raid file system object?

Thanks

    • HulkSmashBurgers@reddthat.comOP
      2·
      11 months ago

      I’m not opposed to using something other than luks, it’s just what I’m familiar with. Is there some other better approach you could recommend?

      • lurch (he/him)@sh.itjust.works
        1·
        11 months ago

        I mean that any attack gets more easy when you know, after it’s decrypted there are the bytes A, B and C at the locations X, Y and Z. It helps with brute force as well as hybrid attacks to find the master key.

        LUKS does exactly have those specific Bytes at specific locations PLUS it has a marker that basically says “I am in this format and encrypted with this algorythm”.

        • LoveSausage
          11·
          11 months ago

          Interesting. But is that issue not mitigated by using a good passphrase ? Been using luks as default for years. Any better option for full disk encryption on Linux ?

          • lurch (he/him)@sh.itjust.works
            1·
            11 months ago

            A good pasphrase helps the same for non-LUKS, but they still don’t have that specific weakness.

            You can use cryptsetup without LUKS. However, something that starts to decrypt has to be unencryoted, so you can enter the password. Depending on how convenient it is for the user, it will leak some helpful info, like for example that the target is a valid file system that can be mounted or what cipher had been used.

            to conceal this, you’d have to enter all it does manually in a shell/script without history. You could also add a number of bytes to skip as a sort of extra password and fill the start with random bytes, so it’s harder to find the start of the payload that is peobably a file system.