this post was submitted on 01 Jan 2024
7 points (88.9% liked)

Guix

274 readers
1 users here now

Guix is an advanced distribution of the GNU operating system developed by the GNU Project

founded 4 years ago
MODERATORS
 

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

top 6 comments
sorted by: hot top controversial new old
[–] [email protected] 2 points 6 months ago (2 children)

You sure you want to use LUKS? It has a specific format that can be probed for almost like a known plain text.

[–] [email protected] 2 points 6 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?

[–] [email protected] 1 points 6 months ago (1 children)

https://devicetests.com/secure-luks-encryption had to Google that, if you want to brute force your way into a modern like setup you either need a weak password or a very powerful computer and time/money.. or do you mean something else?

[–] [email protected] 1 points 6 months ago* (last edited 6 months ago) (1 children)

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".

[–] [email protected] 0 points 6 months ago (1 children)

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 ?

[–] [email protected] 1 points 6 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.