Luks2, new cryptosetup release, new Qubes?

User Support General
1

Hello dear community !
I’m about to get my updated laptop, and look forward to make a fresh-new install of Qubes.
** What I want is to have a setup that I won’t have to change in a couple of months** hence me trying to already setup it up with the higher and greater options.

Last time I tried, Cryptosetups has no option for Luks2 (with Argon2) or at least none that worked.
I wanted to have my /boot on a SDcard, I gave-up
I also gave up on mk partitions prior to install, as Qubes installer would freez/crash everytime
I gave up on tweaking cryptosetup option (higher hash, etc …) as installer would crash

Now, as I see the Qubes version is 4.1.1 while the same I last tried was 4.1, I assume there is no much change in it ?
I’m even considering having Luks1 for /boot and Luks2 for remaining BTRFS (for easy support from GRUB)

What do you say ? IS there a support for Luks2 / Argon2 / Grub in the latest realease, or the one to come soon ? (should I wait for 4.1.2 or 4.2)

Thks !

2 Likes
2

I should have added:
Is there an easy way to upgrade Luks1 to Luks2 on an already installed drive ?
Changing the hashing option, changing the crypto etc …

3

When you run the Qubes installer, it automatically uses LUKS/dm-crypt in the background to implement full-disk encryption (FDE). You don’t have to interact directly with LUKS at all, and you don’t have to worry about the version of LUKS. You can simply run the installer, follow the instructions and prompts, and your Qubes installation will be be fully encrypted (except for the boot partition, of course).

Customizing the LUKS options is not necessary, since LUKS already ships with secure defaults. If you still want to customize the LUKS options anyway: Sorry, I don’t know how to do that in 4.1.

4

You can manually partition and encrypt the disk from tty (CTRL+ALT+F2), then go back to gui (CTRL+ALT+F6), refresh the drives, select custom, select the partitions and proceed with installation.

Example script below (assumption: the destination drive is /dev/nvme0n1):

# Fill drive with random data
dd if=/dev/urandom of=/dev/nvme0n1 bs=1M status=progress

# Partition drive
sgdisk --zap-all /dev/nvme0n1 
sgdisk --clear /dev/nvme0n1 
sgdisk -n 1:0:+200MiB -t 1:ef00 /dev/nvme0n1 
sgdisk -n 2:0:+1000MiB -t 2:8300 /dev/nvme0n1 
echo "y" | mkfs.ext2 /dev/nvme0n1p2
sgdisk -N 3 -t 3:8300 /dev/nvme0n1

# Check the partitions
sgdisk --print /dev/nvme0n1 

# Encrypt root partition
cryptsetup -c aes-xts-plain64 -h sha512 -s 512 --type luks2 --use-random -q -y --force-password -i 10000 luksFormat /dev/nvme0n1p3
cryptsetup luksOpen /dev/nvme0n1p3 luks-root

# Create LV group
pvcreate /dev/mapper/luks-root
vgcreate qubes_dom0 /dev/mapper/luks-root

lvcreate -L 40G -T qubes_dom0/root-pool
lvcreate -V30G -T qubes_dom0/root-pool -n root

lvcreate -l +90%FREE -T qubes_dom0/vm-pool
# Define vm_lv_size before running the next command
lvcreate -V"${vm_lv_size}"G -T qubes_dom0/vm-pool -n vm
mkfs.ext4 /dev/qubes_dom0/vm

# Check LV
lvs

This guide is more thorough: Qubes OS Installation - Detached encrypted boot and header

1 Like
5

Not really Qubes-specific but here you go

cryptsetup convert <device> --type <format>

              Converts the device between LUKS1 and LUKS2 format (if
              possible).  The conversion will not be performed if there
              is an additional LUKS2 feature or LUKS1 has unsupported
              header size.

              Conversion (both directions) must be performed on inactive
              device. There must not be active dm-crypt mapping
              established for LUKS header requested for conversion.

              --type option is mandatory with following accepted values:
              luks1 or luks2.

              WARNING: The convert action can destroy the LUKS header in
              the case of a crash during conversion or if a media error
              occurs.  Always create a header backup before performing
              this operation!

              <options> can be [--header, --type].

https://www.man7.org/linux/man-pages/man8/cryptsetup.8.html

1 Like
6

Thank you, but I think you completely miss the point :wink:

1 Like
7

Thank you, yes, but if you read my first post, I’m saying that I’m already using this, and every time I go back to the installer, it freeze/crash (-“I gave up on tweaking cryptosetup option (higher hash, etc …) as installer would crash”)
I’m not sure why, as the T440p is recognized as stable for Qubes

8

Thank you. OK, so that means I would have to take the 2280 out of the box, and plug it in an adapter to be used as USB disk on another machine. So far it is feasible, just have to purchase an adapter.
Then there is the header backup/restore, and the corruption possibilities.

That says the conversion from Luck1 to Luck2 (and vice-versa) is indeed possible, mais that doesn’t tell me how QUBES (and Grub) will react to it ?

9

Or do so from a live usb or the qubes os installer. Much simpler.

cryptsetup luksHeaderBackup <device> --header-backup-file <file>
cryptsetup luksHeaderRestore <device> --header-backup-file <file>

Could you be a bit clearer with what you’re trying to achieve? The root partition should be encrypted with LUKS2 by default anyway, so what’s the deal with the conversion?

Then the answer to your original question is: yes, there is support for LUKS2 in the latest release

1 Like
10

Sure !
I’m targeting an installation that I won’t have to change/update anytime soon, therefore aiming at maximizing this setup so it last for the next few years, hence me wiling to get LUKS2 with at least 512 ash and Argon2 etc …

11

Thks a lot for these, it’s very appreciated !!

12

Oh ! hum … I missed that one … so I see I haven’t done a proper investigation job before posting :frowning: Sorry about that, and thank you for -still- answering my questions without judging :confused:

13

No worries.

Once you are in dom0, you can verify all the parameters with:

sudo cryptsetup luksDump /dev/<luks-device>
1 Like
14

Actually @Erica.vH it would be interesting to know the default parameters.
Could you post the output of the following command, please?

sudo cryptsetup luksDump /dev/<luks-device> | grep -E 'Version|cipher|key|PBKDF|Hash'
1 Like
15

I will, as soon as I receive my new laptop and start the installation.
On this one here, as the installation failed x times, I went back to windows … shame
What install I’ve tried:
On a 2TB SSD/HDD hybrid, and a 16GB sdcard
Full automatic install: SD card is just part of the pool, the /boot still instal on the main drive
Full auto intall w/o the sdcard, works. (standard setup 256sha)
Personalized install with /boot on the SDcard => failed.(either (integrated card slot or external usb card reader)
Personalized install with 512sha => failed
Personalized install with a pre-configured partitioning => failed
all in all, anything I tried outside of the standard => failed (on the T440p with 16GB ram => new laptop will hold 128GB ram)

16

To diagnose a problem we’d require more info on the error messages (and you should open a separate thread).

With that said, the installation instructions I provided above should be pretty fail-proof, so if you insist on modifying the luks option, that method would most likely work, since it pretty much on the installer to do all the post-install work. Otherwise just go standard and see what the default parameters are.

1 Like
17

Even default:
“(fresh Qubes 4.1 install uses LUKS2 for disk encryption, while earlier versions use LUKS1).”
Source:

3 Likes
18

Clean installation of 4.1.1:

Version:       	2
	cipher: aes-xts-plain64
	Cipher key: 512 bits
	PBKDF:      argon2i
	Hash:       sha256
1 Like
19

Either these defaults (shipped with cryptsetup) are secure, or they are not:

  1. If they are secure, then there’s no real need to mess with them. (You can if you want, of course, but it’ll probably be more trouble than it’s worth.)

  2. If they are not, then you should report this to the cryptsetup maintainers so that they can fix it and ship secure defaults.

1 Like
20

Cheers adw, these look safe indeed.

The only difference with the modified parameters I mentioned above is the hash used to create the encryption key, as the default is sha256 while I used sha512.

I would agree that for the regular user it’s arguably better to not mess with them, with the risk of lowering the security, but it would also be interesting to understand why sha512 is not the default.

2 Likes