| View previous topic :: View next topic |
| Author |
Message |
lfs0a
Tux's lil' helper
Joined: 19 Oct 2016
Posts: 136
|
 Posted: Tue Jun 25, 2024 2:40 pm Post subject: [SOLVED]Some doubts about LUKS2&dmcrypt |
 |
|
Hi guys,
I've managed to setup full disk encryption with LUKS2,(root partition encrypted with an ESP,an ext4 /boot partition)
Now I'm wandering:
1: when I reboot or shutdown,does it automatically umount and re-encrypt /?
2:I force it to encrypt 60 seconds,but after I input the passphrase,I took about 4-5 minutes to decrypt,why?(8250U, about 300G SSD, benchmark XTS about 2300MB/S)
Thanks in advance.
Last edited by lfs0a on Sun Jul 14, 2024 9:50 am; edited 1 time in total |
|
| Back to top |
|
 |
sublogic
Apprentice
Joined: 21 Mar 2022
Posts: 270
Location: Pennsylvania, USA
|
| Posted: Tue Jun 25, 2024 11:59 pm Post subject: Re: Some doubts about LUKS2&dmcrypt |
|
|
| lfs0a wrote: | Hi guys,
I've managed to setup full disk encryption with LUKS2,(root partition encrypted with an ESP,an ext4 /boot partition) |
Just so we are on the same page: your ESP and /boot partitions are cleartext, and the rest are LVM logical volumes in a LUKS2-encrypted partition that spans the rest of the disk ?
| Quote: | Now I'm wandering:
1: when I reboot or shutdown,does it automatically umount and re-encrypt /? |
It's always encrypted. To illustrate with my own setup: | Code: | $ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 465.8G 0 disk
├─sda1 8:1 0 8M 0 part
├─sda2 8:2 0 256M 0 part
└─sda3 8:3 0 465.5G 0 part
└─root 254:0 0 465.5G 0 crypt
├─vg0-root 254:1 0 40G 0 lvm /
├─vg0-var 254:2 0 40G 0 lvm /var
├─vg0-home 254:3 0 40G 0 lvm /home
└─vg0-swap 254:4 0 64G 0 lvm [SWAP] |
My root partition is /dev/mapper/vg0-root. I also have /dev/mapper/vg0-home, /dev/mapper/vg0-var and /dev/mapper/vg0-swap. Above them, /dev/mapper/root is their LVM container (bad name, it is an LVM volume group and not the root partition). These are all virtual block devices. /dev/mapper/root is also the cleartext of /dev/sda3 past the LUKS header.
Encryption and decryption is done on demand as I/O is happens through the virtual block devices. Anything written to /dev/mapper/vg0-root (or -home, or -var, or -swap) is mapped to a part of /dev/mapper/root; from there it is encrypted and, finally written to /dev/sda3 on the disk. No cleartext ever hits the disk. When you shutdown, the cleartext devices disappear and only encrypted data remains. When you reboot, your initramfs prompts you for a passphrase, brings back the virtual devices and finishes booting to the decrypted root.
| Quote: | | 2:I force it to encrypt 60 seconds, |
I don't understand. What command did you run to do that, and at what stage ?
| Quote: | | but after I input the passphrase,I took about 4-5 minutes to decrypt,why?(8250U, about 300G SSD, benchmark XTS about 2300MB/S) |
I speculate that you overdid the key derivation parameters. Your passphrase is not the volume key, your passphrase is used to encrypt the volume key before storing it in the LUKS header. Furthermore, your passphrase is not used directly: it is hashed repeatedly with an expensive function and it is the final digest that encrypts the volume key. This is to mitigate attacks against weak passphrases. When you run luksFormat you decide how expensive this step must be if you don't like the defaults.
If that is your predicament, you can run cryptsetup luksAddKey to add a new passphrase with easier hash parameters. There is only one volume key but you can have up to 32 passphrases. When you add a new one, you are asked for the new passphrase but you also have to type a valid existing passhprase and it will take 4-5 minutes to add the new key. You can pass --key-slot number to luksOpen to test the new passphrase. If all is well you can run cryptsetup luksKillSlot to delete the slow one.
IF YOU KILL ALL YOUR KEY SLOTS, YOUR DATA IS GONE FOREVER !!. So be careful. Read all the cryptsetup man pages. Consider running cryptsetup luksHeaderBackup and save a copy of the LUKS header to a USB thumb drive. And test the backup header ! |
|
| Back to top |
|
|
lfs0a
Tux's lil' helper
Joined: 19 Oct 2016
Posts: 136
|
| Posted: Wed Jun 26, 2024 12:49 am Post subject: Re: Some doubts about LUKS2&dmcrypt |
|
|
| sublogic wrote: | | lfs0a wrote: | Hi guys,
I've managed to setup full disk encryption with LUKS2,(root partition encrypted with an ESP,an ext4 /boot partition) |
Just so we are on the same page: your ESP and /boot partitions are cleartext, and the rest are LVM logical volumes in a LUKS2-encrypted partition that spans the rest of the disk ?
| Quote: | Now I'm wandering:
1: when I reboot or shutdown,does it automatically umount and re-encrypt /? |
It's always encrypted. To illustrate with my own setup: | Code: | $ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 465.8G 0 disk
├─sda1 8:1 0 8M 0 part
├─sda2 8:2 0 256M 0 part
└─sda3 8:3 0 465.5G 0 part
└─root 254:0 0 465.5G 0 crypt
├─vg0-root 254:1 0 40G 0 lvm /
├─vg0-var 254:2 0 40G 0 lvm /var
├─vg0-home 254:3 0 40G 0 lvm /home
└─vg0-swap 254:4 0 64G 0 lvm [SWAP] |
My root partition is /dev/mapper/vg0-root. I also have /dev/mapper/vg0-home, /dev/mapper/vg0-var and /dev/mapper/vg0-swap. Above them, /dev/mapper/root is their LVM container (bad name, it is an LVM volume group and not the root partition). These are all virtual block devices. /dev/mapper/root is also the cleartext of /dev/sda3 past the LUKS header.
Thanks for reply,sublogic.
1,I did it without LVM,the ESP and /boot partitions are cleartext.
2,There is a /etc/init.d/dmcrypt which I added to boot runlevel,should I?
3,I did something with the derivation parameters,my questions is ,It took about 5 minutes to decrypt,what did it do in the 4 minutes after derivation?
Have a nice day!
Encryption and decryption is done on demand as I/O is happens through the virtual block devices. Anything written to /dev/mapper/vg0-root (or -home, or -var, or -swap) is mapped to a part of /dev/mapper/root; from there it is encrypted and, finally written to /dev/sda3 on the disk. No cleartext ever hits the disk. When you shutdown, the cleartext devices disappear and only encrypted data remains. When you reboot, your initramfs prompts you for a passphrase, brings back the virtual devices and finishes booting to the decrypted root.
| Quote: | | 2:I force it to encrypt 60 seconds, |
I don't understand. What command did you run to do that, and at what stage ?
| Quote: | | but after I input the passphrase,I took about 4-5 minutes to decrypt,why?(8250U, about 300G SSD, benchmark XTS about 2300MB/S) |
I speculate that you overdid the key derivation parameters. Your passphrase is not the volume key, your passphrase is used to encrypt the volume key before storing it in the LUKS header. Furthermore, your passphrase is not used directly: it is hashed repeatedly with an expensive function and it is the final digest that encrypts the volume key. This is to mitigate attacks against weak passphrases. When you run luksFormat you decide how expensive this step must be if you don't like the defaults.
If that is your predicament, you can run cryptsetup luksAddKey to add a new passphrase with easier hash parameters. There is only one volume key but you can have up to 32 passphrases. When you add a new one, you are asked for the new passphrase but you also have to type a valid existing passhprase and it will take 4-5 minutes to add the new key. You can pass --key-slot number to luksOpen to test the new passphrase. If all is well you can run cryptsetup luksKillSlot to delete the slow one.
IF YOU KILL ALL YOUR KEY SLOTS, YOUR DATA IS GONE FOREVER !!. So be careful. Read all the cryptsetup man pages. Consider running cryptsetup luksHeaderBackup and save a copy of the LUKS header to a USB thumb drive. And test the backup header ! |
|
|
| Back to top |
|
|
sublogic
Apprentice
Joined: 21 Mar 2022
Posts: 270
Location: Pennsylvania, USA
|
| Posted: Wed Jun 26, 2024 9:57 pm Post subject: Re: Some doubts about LUKS2&dmcrypt |
|
|
| lfs0a wrote: | Thanks for reply,sublogic.
1,I did it without LVM,the ESP and /boot partitions are cleartext. |
OK. That's simple. You have a root partition with everything on in, and no swap.
(I didn't ask, but: you have an initramfs that prompts you for a passphrase and sets up the encrypted root ?)
| Quote: | | 2,There is a /etc/init.d/dmcrypt which I added to boot runlevel,should I? |
You don't need it. It opens additional encrypted partitions after root is mounted, and you don't have any. Look at /etc/conf.d/dmcrypt if you're curious.
| lfs0a wrote: | | 3,I did something with the derivation parameters,my questions is ,It took about 5 minutes to decrypt,what did it do in the 4 minutes after derivation? |
I don't know what's going on here. I'll repeat my question:
| lfs0a wrote: | | I force it to encrypt 60 seconds |
What does that mean ? What command did you run, and at what stage of the installation ? |
|
| Back to top |
|
|
lfs0a
Tux's lil' helper
Joined: 19 Oct 2016
Posts: 136
|
| Posted: Sun Jun 30, 2024 7:22 am Post subject: Re: Some doubts about LUKS2&dmcrypt |
|
|
| sublogic wrote: | | lfs0a wrote: | Thanks for reply,sublogic.
1,I did it without LVM,the ESP and /boot partitions are cleartext. |
OK. That's simple. You have a root partition with everything on in, and no swap.
(I didn't ask, but: you have an initramfs that prompts you for a passphrase and sets up the encrypted root ?)
| Quote: | | 2,There is a /etc/init.d/dmcrypt which I added to boot runlevel,should I? |
You don't need it. It opens additional encrypted partitions after root is mounted, and you don't have any. Look at /etc/conf.d/dmcrypt if you're curious.
| lfs0a wrote: | | 3,I did something with the derivation parameters,my questions is ,It took about 5 minutes to decrypt,what did it do in the 4 minutes after derivation? |
I don't know what's going on here. I'll repeat my question:
| lfs0a wrote: | | I force it to encrypt 60 seconds |
What does that mean ? What command did you run, and at what stage of the installation ? |
Yes,I have an initramfs.
The /etc/init.d/dmcrypt is not doing "cryptset close" kind of works when I'm shutdown my computer?
There is no need to "cryptset close"
luksformat --iter-time 60000
Have a nice day! |
|
| Back to top |
|
|
sublogic
Apprentice
Joined: 21 Mar 2022
Posts: 270
Location: Pennsylvania, USA
|
| Posted: Mon Jul 01, 2024 12:27 am Post subject: Re: Some doubts about LUKS2&dmcrypt |
|
|
| lfs0a wrote: | | Yes,I have an initramfs. |
Good.
| lfs0a wrote: | | luksformat --iter-time 60000 |
There's your problem. That doesn't do what you think it does.
You can restore the default with | Code: | | # cryptsetup luksChangeKey --iter-time=2000 /dev/_whatever_ |
It will ask for the passphrase of the keyslot you want to modify (and you only have one, so no ambiguity; type your passphrase). It will run for 5 minutes. Let it finish. After that, your luksOpens will only take a couple of seconds. (Only you know what to substitute for /dev/_whatever_ .)
EDIT: it also asks for a new passphrase and confirmation of the new passphrase. Okay to reuse the original passphrase.
As far as I know it is safe to do this on a live system. I will run a few tests here to confirm, but see PRECAUTIONS below.
EDIT: yep, it looks safe. See below for details.
| lfs0a wrote: | The /etc/init.d/dmcrypt is not doing "cryptset close" kind of works when I'm shutdown my computer?
There is no need to "cryptset close" |
Not needed. When you shut down, all processes stop and the file systems are remounted read-only. When the kernel is about to stop and cut power, the dmcrypt mapping is still live, but no I/O will ever go through it anymore. The mapping resides in kernel memory, not on disk. Like everything else in kernel memory at this point, it can be forgotten.
PRECAUTIONS
You need to understand what follows and take responsibility for adverse consequences. The luksChangeKey operation modifies the LUKS header at the beginning of the encrypted partition and does not touch the encrypted data. It has no effect on the live dmcrypt mapping in the kernel, so I/O to and from the encrypted region works the whole time and continues to work. That said, if anything goes wrong and the LUKS header is corrupted you lose everything at the next reboot. To avoid a reinstall from scratch,
- Mount your boot partition and run cryptsetup luksHeaderBackup to save a copy of your LUKS header to your unencrypted boot partition. Read the man page for details.
- Read the man page for cryptsetup-luksHeaderRestore and take some notes.
- Have rescue media handy in case your system won't reboot; and/or,
- learn how to boot to a rescue shell in your initramfs; both dracut and genkernel support this; details depend on your bootloader; you can probably repair from an initramfs shell instead of rescue media --and even finish booting.
- Now run the luksChangeKey command.
- If disaster strikes, get to a rescue environment, mount the boot partition and run cryptsetup LuksHeaderRestore to repair your corrupted header.
This puts you back at the starting point: a working boot sequence that takes 5 minutes. You can try the luksChangeKey again from a rescue environment, and you still have that header backup if that fails again.
(In addition, it never hurts to have a full backup of your system ...)
If all goes well you may want to run shred on the header backup. Also you should read the cryptsetup FAQ at least once,
https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions .
-----------------------------------------------------------------------------------------------------
EDIT: what I did to confirm safety:- Allocate a big file.
- Connect it to /dev/loop0 with losetup(1) .
- luksFormat /dev/loop0 with --iter-time=20000; that took 59 seconds. (NB: twenty thousand, not two thousand.)
- luksOpen /dev/loop0; that took 20 seconds.
- mkfs on /dev/loop0 and mount the resulting file system.
- cp -a /var/db/pkg to put some data on it.
- diff -r --brief to verify the copy. No differences.
- luksChangeKey with --iter-time=2000 with the fs still mounted; that took 56 seconds.
- diff -r --brief again. No differences.
- umount, cryptsetup close.
- luksOpen again; now it took 2 seconds.
- mount the file system again.
- diff -r --brief . Still no differences.
- umount, close, remove the big file.
That tells me it is safe to change LUKS keys on a live mapping. It just gets exciting when that mapping is for your root filesystem  . |
|
| Back to top |
|
|
lfs0a
Tux's lil' helper
Joined: 19 Oct 2016
Posts: 136
|
| Posted: Sun Jul 14, 2024 4:35 am Post subject: Re: Some doubts about LUKS2&dmcrypt |
|
|
Thanks for the tests,sublogic!
I used --iter-time 60000 intentionally to reduce the possibility to brute force into my computer.
You have a nice day 
| sublogic wrote: | | lfs0a wrote: | | Yes,I have an initramfs. |
Good.
| lfs0a wrote: | | luksformat --iter-time 60000 |
There's your problem. That doesn't do what you think it does.
You can restore the default with | Code: | | # cryptsetup luksChangeKey --iter-time=2000 /dev/_whatever_ |
It will ask for the passphrase of the keyslot you want to modify (and you only have one, so no ambiguity; type your passphrase). It will run for 5 minutes. Let it finish. After that, your luksOpens will only take a couple of seconds. (Only you know what to substitute for /dev/_whatever_ .)
EDIT: it also asks for a new passphrase and confirmation of the new passphrase. Okay to reuse the original passphrase.
As far as I know it is safe to do this on a live system. I will run a few tests here to confirm, but see PRECAUTIONS below.
EDIT: yep, it looks safe. See below for details.
| lfs0a wrote: | The /etc/init.d/dmcrypt is not doing "cryptset close" kind of works when I'm shutdown my computer?
There is no need to "cryptset close" |
Not needed. When you shut down, all processes stop and the file systems are remounted read-only. When the kernel is about to stop and cut power, the dmcrypt mapping is still live, but no I/O will ever go through it anymore. The mapping resides in kernel memory, not on disk. Like everything else in kernel memory at this point, it can be forgotten.
PRECAUTIONS
You need to understand what follows and take responsibility for adverse consequences. The luksChangeKey operation modifies the LUKS header at the beginning of the encrypted partition and does not touch the encrypted data. It has no effect on the live dmcrypt mapping in the kernel, so I/O to and from the encrypted region works the whole time and continues to work. That said, if anything goes wrong and the LUKS header is corrupted you lose everything at the next reboot. To avoid a reinstall from scratch,
- Mount your boot partition and run cryptsetup luksHeaderBackup to save a copy of your LUKS header to your unencrypted boot partition. Read the man page for details.
- Read the man page for cryptsetup-luksHeaderRestore and take some notes.
- Have rescue media handy in case your system won't reboot; and/or,
- learn how to boot to a rescue shell in your initramfs; both dracut and genkernel support this; details depend on your bootloader; you can probably repair from an initramfs shell instead of rescue media --and even finish booting.
- Now run the luksChangeKey command.
- If disaster strikes, get to a rescue environment, mount the boot partition and run cryptsetup LuksHeaderRestore to repair your corrupted header.
This puts you back at the starting point: a working boot sequence that takes 5 minutes. You can try the luksChangeKey again from a rescue environment, and you still have that header backup if that fails again.
(In addition, it never hurts to have a full backup of your system ...)
If all goes well you may want to run shred on the header backup. Also you should read the cryptsetup FAQ at least once,
https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions .
-----------------------------------------------------------------------------------------------------
EDIT: what I did to confirm safety:- Allocate a big file.
- Connect it to /dev/loop0 with losetup(1) .
- luksFormat /dev/loop0 with --iter-time=20000; that took 59 seconds. (NB: twenty thousand, not two thousand.)
- luksOpen /dev/loop0; that took 20 seconds.
- mkfs on /dev/loop0 and mount the resulting file system.
- cp -a /var/db/pkg to put some data on it.
- diff -r --brief to verify the copy. No differences.
- luksChangeKey with --iter-time=2000 with the fs still mounted; that took 56 seconds.
- diff -r --brief again. No differences.
- umount, cryptsetup close.
- luksOpen again; now it took 2 seconds.
- mount the file system again.
- diff -r --brief . Still no differences.
- umount, close, remove the big file.
That tells me it is safe to change LUKS keys on a live mapping. It just gets exciting when that mapping is for your root filesystem . |
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Other Things Gentoo
