For a key, I recommend /dev/random instead of /dev/urandom. The former ensures high entropy. (though I don’t know the answer to the rest of your question)
If you’re talking about this:
dd if=/dev/urandom of=key.img bs=32M count=1
Then I think it shouldn’t really matter because cryptsetup will use /dev/random when it’ll initialize a LUKS partition here:
cryptsetup luksFormat key.img
And the key used to encrypt /dev/sda later won’t be raw key.img file created from /dev/urandom but the decrypted key.img file that was encrypted with key from /dev/random.
I’ve looked into it more and luksFormat is using /dev/urandom by default:
#cryptsetup --help
Default compiled-in device cipher parameters:
loop-AES: aes, Key 256 bits
plain: aes-cbc-essiv:sha256, Key: 256 bits, Password hashing: ripemd160
LUKS: aes-xts-plain64, Key: 256 bits, LUKS header hashing: sha256, RNG: /dev/urandom
LUKS: Default keysize with XTS mode (two internal keys) will be doubled.
So maybe it’ll make sense to add --use-random
option to cryptsetup luksFormat command.
But there’s a note in arch wiki about it:
Note that /dev/random blocking pool has been removed. Therefore,
--use-random
flag is now equivalent to--use-urandom
.
So maybe using /dev/random is pointless.
I have paid 50% of my donation as promised. $250 via xmr to Qubes. Will pay the balance when you publish. I Send you PM with txid for proof.
Will do in the next 24h.
Progress
Part 2 of Playing with qubes
Is a rewrite of my old notes, Qubes OS Installation - Detached encrypted boot and header
This will cover how you use it with xfs and btrfs on dom0
This is UEFI based only.
-
Prerequisite :
- QubesOS Installation Medium.
- 2 Drives for separated Root and Boot/EFI Partition, and we would call them with :
- Root = /dev/nvme0n1
- Boot = /dev/sda
-
After booting into installation in language section, press ctrl + alt + f2 to enter tty2
-
Format drive we would use for the installation.
-
dd if=/dev/urandom of=/dev/nvme0n1 bs=1M status=progress
-
dd if=/dev/urandom of=/dev/sda bs=1M status=progress
-
-
Create Boot, EFI, Header Partition.
-
sgdisk -n 0:0:+200MiB -t 0:ef02 /dev/sda
-
sgdisk -n 0:0:+200MiB -t 0:ef00 /dev/sda
-
sgdisk -n 0:0:+16MiB -t 0:8309 /dev/sda
-
XFS
-
Create custom Luks configuration.
-
cryptsetup -c aes-xts-plain64 -h sha512 -s 512 -y -i 10000 luksFormat /dev/nvme0n1
You may want to use -i 1 (iterations 1ms) to speed up decrypting process for practice.
-
cryptsetup luksOpen /dev/nvme0n1 luks-root
-
pvcreate /dev/mapper/luks-root
-
vgcreate qubes_dom0 /dev/mapper/luks-root
-
lvcreate -L 8G -n swap qubes_dom0
You might want to read 8.2. Recommended system swap space if you’re not sure about swap space
-
lvcreate -T -L 40G qubes_dom0/root-pool
-
lvcreate -T -l +90%FREE qubes_dom0/vm-pool
-
lvcreate -V30G -T qubes_dom0/root-pool -n root-pool
-
lvs
To see how much space you have in the vm-pool, and use it to create vm lv.
-
lvcreate -V800G -T qubes_dom0/vm-pool -n vm
-
mkfs.xfs /dev/qubes_dom0/vm
-
mkswap /dev/mapper/swap
-
BTRFS
- Create Root and Swap Partition.
-
sgdisk -n 0:0:+8GiB -t 0:8200 /dev/nvme0n1
-
sgdisk -n 0:0:0 -t 0:8304 /dev/nvme0n1
-
- Create custom Luks configuration.
-
cryptsetup -c aes-xts-plain64 -h sha512 -s 512 -y -i 10000 luksFormat /dev/nvme0n1p1
-
cryptsetup -c serpent-xts-plain64 -h sha512 -s 512 -y -i 10000 luksFormat /dev/nvme0n1p2
-
cryptsetup luksOpen /dev/nvme0n1p1 luks-root
-
cryptsetup luksOpen /dev/nvme0n1p2 luks-swap
-
mkfs.btrfs --csum blake2b -L qubes_dom0 -d single /dev/mapper/luks-root
-
mkswap /dev/mapper/swap
-
Proceed GUI Installation
Video / Pict ?
Begin installation.
-
After installation go back to tty2
-
cp -r /usr/lib/grub/x86_64-efi /mnt/sysroot/boot/efi/EFI/qubes/
-
chroot /mnt/sysroot/
-
mount -oremount,ro /boot
-
install -m0600 /dev/null /tmp/boot.tar
-
tar -C /boot --acls --xattrs --one-file-system -cf /tmp/boot.tar .
-
umount /boot/efi
-
umount /boot
-
-
Reformat Boot Partition
-
cryptsetup -c twofish-xts-plain64 -h sha512 -s 512 -y -i 1 --use-random --type luks1 luksFormat /dev/sdb1
-
uuidR="$(blkid -o value -s UUID /dev/nvme0n1)"
-
uuidB="$(blkid -o value -s UUID /dev/sda1)"
-
cryptsetup luksOpen /dev/sda1 luks-$uuidB
-
mkfs.xfs /dev/mapper/luks-$uuidB
-
xfs_admin -U $uuidB /dev/mapper/luks-$uuidB
-
-
Configure fstab
-
sed -i ‘s/dev/mapper/root/dev/mapper/luks-’$uuidR’\g’ /etc/fstab
-
sed -i ‘s\UUID=F4N*/dev/mapper/luks-’$uuidR’\g’ /etc/fstab
Replace F4N with First 4 UUID Number of /dev/sda1
-
mount -v /boot
-
tar -C /boot --acls --xattrs -xf /tmp/boot.tar
-
mount /dev/sda1 /boot/efi
-
-
Configure keys
-
mkdir -m0700 /etc/keys
-
( umask 0077 && dd if=/dev/urandom bs=1 count=64 of=/etc/keys/root.key conv=excl,fsync )
-
( umask 0077 && dd if=/dev/urandom bs=1 count=64 of=/etc/keys/boot.key conv=excl,fsync )
-
cryptsetup luksAddKey /dev/nvme0n1 /etc/keys/root.key
-
cryptsetup luksAddKey /dev/sda1 /etc/keys/boot.key
-
cryptsetup luksHeaderBackup /dev/nvme0n1 --header-backup-file header
-
dd if=/header of=/dev/sda3 bs=16M count=1 status=progress
-
shred -uvz /header
-
shred -uvz /tmp/boot.tar
-
-
Configure Crypttab
-
echo -e “luks-$uuidR /dev/nvme0n1 /etc/keys/root.key luks,discard,key-slot=1,header=/dev/sda3\nluks-$uuidB UUID=$uuidB /etc/keys/boot.key luks,key-slot=1” > /etc/crypttab
-
-
Configure GRUB
-
echo “GRUB_ENABLE_CRYPTODISK=y” >> /etc/default/grub
-
sed btrfs driver # TODO
-
grub2-mkconfig -o /boot/efi/EFI/qubes.cfg
-
-
Configure Dracut
-
echo -e ‘add_dracutmodules+=" crypt “\ninstall_items+=” /etc/keys/root.key /etc/keys/boot.key ”’ > /etc/dracut.conf.d/qubes.conf
-
sed -i ‘s?block_uuid.map"?block_uuid.map"\necho “/dev/nvme0n1 ‘$uuidR’\n/dev/disk/by-uuid/’$uuidB’ ‘$uuidB’" > “${initdir}/etc/block_uuid.map”?g’ /usr/lib/dracut/modules.d/90crypt/module-setup.sh
-
sed -i ‘s?$initdir/etc/crypttab?$initdir/etc/crypttab\necho “luks-’$uuidR’ /dev/nvme0n1 /etc/keys/root.key luks,discard,key-slot=1,header=/dev/sda3\nluks-’$uuidB’ UUID=’$uuidB’ /etc/keys/boot.key luks,key-slot=1” > $initdir/etc/crypttab?g’ /usr/lib/dracut/modules.d/90crypt/module-setup.sh
-
dracut -vf /boot/initramfs-*
-
exit
-
umount /mnt/sysroot/boot/efi
-
umount /mnt/sysroot/boot
-
umount -l /mnt/sysroot
-
umount -l /mnt/sysimage
-
swapoff /dev/qubes_dom0/swap
-
vgchange -a n qubes_dom0
-
cryptsetup luksClose /dev/mapper/luks-root
-
cryptsetup luksClose /dev/mapper/luks-*
-
wipefs -a /dev/nvme0n1
-
reboot
-
- Will tested tomorrow on my machine
- Check for typo
- Record video how to do this (will use vm).
I will try later, I remember in my first research, it failed.
don’t bother with the error, just proceed you’ll be fine, and you may want to follow the progress above instead of #1, and look for #1 or in btrfs thread for the image.
Maybe it’ll work if you use PARTUUID /dev/disk/by-partuuid/ instead of UUID?
UUID is a filesystem-level UUID, which is retrieved from the filesystem metadata inside the partition. It can only be read if the filesystem type is known and readable.
PARTUUID is a partition-table-level UUID for the partition, a standard feature for all partitions on GPT-partitioned disks. Since it is retrieved from the partition table, it is accessible without making any assumptions at all about the actual contents of the partition. If the partition is encrypted using some unknown encryption method, this might be the only accessible unique identifier for that particular partition.
fstab - What is UUID, PARTUUID and PTUUID? - Unix & Linux Stack Exchange

Maybe it’ll work if you use PARTUUID /dev/disk/by-partuuid/ instead of UUID?
I’m not sure, if you look at my approach I wrote the header on the partition, so the partition will have the same metadata as root.
I’m surprised by this,

I’ve tried it out by configuring LUKS like this:
it actually work.
I think, it’s not necessary, I did shred on both boot.rar and header

I’m not sure, if you look at my approach I wrote the header on the partition, so the partition will have the same metadata as root.
I assume that because you’re writing just header on raw partition then there is no filesystem there so there is no UUID for this partition. But this partition still has PARTUUID and could be addressed with /dev/disk/by-partuuid/.

I think, it’s not necessary, I did shred on both boot.rar and header
Shred works fine for HDD, but it doesn’t work for SSD:
dm-crypt/Specialties - ArchWiki

I assume that because you’re writing just header on raw partition then there is no filesystem there so there is no UUID for this partition. But this partition still has PARTUUID and could be addressed with /dev/disk/by-partuuid/.
I’ve checked it myself and my guess was wrong. When you write header to the raw partition then it’ll have UUID of the luks partition.

Shred works fine for HDD, but it doesn’t work for SSD
Ah i see, that make sense with ssd but still, I think one need to bypass crypt first to examine this. But your approach to creating detach header before installation is acceptable, I’ve add it to my note, but not with these guide. It has been 1y+ and everything still fine.

I’ve checked it myself and my guess was wrong. When you write header to the raw partition then it’ll have UUID of the luks partition.
As expected.
@51lieal The image seems to be missing from your post. Provided below.
[anaconda /] vi /etc/crypttab
---# Change root device value so it look like this

---

After completion, switch back to shell with ctrl + alt + f2
After completion of the installation in full - meaning upon arrival to the fully installed desktop system? Or after completion of the first part of the installation, prior to booting and putting the LUKS password for the first time and prior to configuration and template installation? Thanks!
Take a look at this for better guide.

Or after completion of the first part of the installation
yes, after first part of installation.
I’ve included video there, you should check.
@51lieal I followed this is exact guide and it worked well but now I would like to switch back to using only the ssd without booting from SD card. Is it possible without reinstalling? I guess I would need to shrink the partition but I don’t know how to do it since the whole disk is encrypted.
@51lieal Please clarify for us when we should use the $uuidR or $uuidB as a variable and when we should use it alphanumerically, thank you.
So is this possible to do with a flashdrive for boot and one for header?
Hello.
So far, I’ve gotten to the point where I entered
tar -C /boot --acls --xattrs --one-file-system -cf /tmp/boot.tar
But every time I tried it, I got this output
tar: Cowardly refusing to create an empty archive
Try 'tar --help' or 'tar --usage' for more information.
I’m sure I followed the instructions, so far, to the letter so where could I have gone wrong?
Not sure how this is going to effect your guides yet (need to dig into it more deeply), but there are big changes coming in grub, though unfortunately qubes 4.1.2 only has grub 2.4.
LUKS2 has been added to grub, though they are still waiting on Argon2i/d, it is in the AUR version.
(Continue in next post, since new users can only include two links…)