CodingCellist/dualboot-arch-windows-encrypted.md

## dualboot-arch-windows-encrypted.md

      
    Raw
  

              dualboot-arch-windows-encrypted.md
            
          
    DISCLAIMER

ENCRYPTING YOUR DRIVE(S) CAN RESULT IN PERMANENT DATA LOSS IF YOU DON'T KNOW
WHAT YOU ARE DOING OR YOU FORGET THE PASSWORD. IT IS YOUR (THE READER'S)
RESPONSIBILITY TO HAVE BACKUPS SHOULD ANYTHING GO WRONG. Additionally, I am not
responsible for any damage you cause to your system by following this guide. You
are completely and solely responsible for any changes made and potential damage
caused.
I am not an expert on this topic in any way! I just read some wiki pages,
had done a dual-boot Arch install before, got inspired by
this reddit guide/thread and decided to see if I could make this work on my
own machine. This document is simply a result of putting that knowledge (most of
which can be found on the Arch Wiki) in one place.
Assumed knowledge

Although this is a step-by-step guide, I will be assuming the reader is familiar
with tools like fdisk or Windows diskmgmt.msc, some system terminology (e.g.
'partitions', 'ESP', 'kernel modules', ...), and (most of) the 'regular'
Arch Install Guide. (If you aren't, read it and/or check out
this other gist by me which details how to do a simple, unencrypted
dual-boot install on the ThinkPad X1 Extreme Gen 1.
Assumed state of machine


I assume the reader has a machine with the most up to date BIOS (if you are
doing this on a ThinkPad X1 Extreme Gen 1, remember that the old BIOS version
can brick your laptop),
two hard drives,
and a working install of Windows on one of the two hard drives.

End result

At the end of this guide, hopefully, you'll have a machine which dual-boots
Windows and Arch Linux, both fully encrypted, with an encrypted, shared
partition, and a pretty EFI bootloader to complement (and launch) it all.
Chapters

Windows Encryption

Why not BitLocker?
Creating an encrypted shared partition

If you already have a shared partition
If you don't already have a shared partition


Encrypting the Windows System Partition

Arch Linux Encryption Setup and Install

Overview
Partitioning
Encrypting

Highly recommended: Backup the LUKS headers


Formatting and Mounting
OPTIONAL: Set up a keyfile for /home
Install Arch
Essential setup
Boot manager setup
Reboot
Install rEFInd
Accessing the shared partition from Linux

Done.
Sources
Windows Encryption

Windows will be encrypted using the VeraCrypt tool. It
is a free, open-source disk encryption tool which I have used for years and has
worked fine for me. It is based on the no-longer maintained "TrueCrypt"
software.
Why not BitLocker?

BitLocker has had some security problems in the past (see this and
this) and is also not available on all Windows editions. By contrast,
VeraCrypt is available for free on any platform (including Linux, which is very
useful when wanting to create an encrypted shared partition).
A couple of other reasons why I like VC is that it supplies its own EFI
bootloader which can then be used from a rescue disk or environment if need be,
and (just to be a bit extra paranoid) that it is not developed by Microsoft
which may have put backdoors in BitLocker.
(That's not to say that there aren't excellent reasons to use BitLocker instead
of VC, notably that VC has had issues with Windows Update. If you want to
use BitLocker instead, then that's fine. Just be aware that in that case I have
no idea if this guide will still work...
UPDATE 2020-07: I had a Windows update change the bootloader back from the
VC one to the default Windows bootloader. This caused Windows to enter what
seems to be known as the "Windows 10 Automatic Repair Loop"; when booting,
Windows would claim that the disk was damaged and try to automatically repair
it. Thankfully however, VC also installs its own bootloader DcsBoot.efi and I
was able to boot into Windows by selecting it from the rEFInd menu. After a
couple of weeks, I accidentally selected the Windows default one again, but
found out that VC (or something) had changed it back to work correctly: it
prompted for my disk password instead of trying automatic repair. So it seems
that the Windows install can still get messed with through Windows update, but
it doesn't seem disastrous (or maybe I was just lucky))
Creating an encrypted shared partition


Launch VeraCrypt
click Create Volume
choose Encrypt a non-system partition/drive
pick Standard or Hidden depending on your needs

If you already have a shared partition


You can either back it up and wipe it by using the
Create encrypted volume and format it option (this will be faster, but you
will lose all data stored on the partition if it is not backed up)
Or you can choose the Encrypt partition in place option which will encrypt
the partition by reading each sector, encrypting it, and then writing the data
back to it (this is slower, but keeps any data you had on the partition)
Pick an encryption algorithm (If read and write speed is very important, most
modern processors have special instructions for AES, so pick that. Otherwise,
pick any algorithm you want; potentially do a benchmark first)
Pick a hash algorithm
Set a password (and if you know what you're doing: use keyfiles, a PIM, etc.)
Move the mouse about randomly until the bar is filled.
If you're extra paranoid, choose a wipe scheme (each number of passes will
heavily increase the time to encrypt, but slightly decreases the likelihood
that someone would be able to figure out what was on the partition before
encrypting it (which is already unlikely))
Finally, click Encrypt and wait for the it to finish.

If you don't already have a shared partition


Create a new partition of the desired size using the diskmgmt.msc tool in
Windows. A new partition can be created anywhere, e.g.

If you have unallocated space on your Windows drive, you could use that
You could shrink the Windows C: partition (which I assume is the
last partition on the Windows drive) using diskmgmt.msc and then use the
freed-up space
You could allocate some space on the second hard drive and use that


Then choose the Create encrypted volume and format it option and select the
relevant partition
Pick an encryption algorithm (If read and write speed is very important, most
modern processors have special instructions for AES, so pick that. Otherwise,
pick any algorithm you want; potentially do a benchmark first)
Pick a hash algorithm
Set a password (and if you know what you're doing: use keyfiles, a PIM, etc.)
Choose whether you will be storing files larger than 4GB on the partition
(this affects what filesystems you can use)
Pick a filesystem (I would use NTFS for its native Windows support and the
Linux support is also decent, especially with the ntfs-3g package) and
leave everything else as is (unless you know what you're doing)
Move the mouse about randomly until the bar is filled, then hit Format and
wait for it to finish.

Encrypting the Windows System Partition


If you've closed it open up VeraCrypt again.
Under the System tab, select Encrypt System Partition/Drive.
Select Normal system encryption and then select
Encrypt the Windows system partition.
Since we will also be installing Arch Linux, select Multi-boot on the next
screen and read and accept the warning VC raises about multi-booting encrypted
operating systems being complex.
Set a password (N.B. When booting, VC only accepts the US keyboard
layout so if you are using a different keyboard layout, I would strongly
recommend only using alphanumerical characters and not use symbols unless
you are 110% certain you know where those symbols are on a US keyboard
layout).

Also note that VeraCrypt changes your keyboard layout to US at this point,
to ensure that the password can be reproduced in the pre-boot environment!

And if you know what you're doing: use keyfiles, a PIM, etc.


Move the mouse about randomly until the bar is filled, then click Next
The next screen tells you the keys have been generated, continue on to the
next screen to create a Rescue Disk.
Create, store, and extract the Rescue Disk to at least one location, e.g. a
USB stick and/or on an external hard disk.

If you are having problems with the verification part, restart this process
from the beginning and then tick the Skip Rescue Disk verification
before you create the Rescue Disk.

N.B. This may be dangerous if the rescue disk was somehow not created
correctly and this was not caught due to the lack of verification, and you
later need the Rescue Disk. If you lose access to the encrypted system for
some reason (not including forgetting the password) and you do not have a
working Rescue Disk, your data will be gone completely.


Continue past the next screen which informs you that the Rescue Disk was
created and what to do with it.
If you're extra paranoid, choose a wipe scheme (each number of passes will
heavily increase the time to encrypt, but slightly decreases the likelihood
that someone would be able to figure out what was on the partition before
encrypting it (which is already unlikely))
To make sure pre-boot authentication, the VC boot loader, etc. actually works
before encrypting your system, VC performs a pre-test. Click the Test button
to install and setup these components, and restart your computer. If
everything works, you should be asked to enter your password, Windows should
boot normally, VC should start back up once you're logged back into Windows,
and then you can continue with the actual encryption.
Back in Windows with VC automatically restarted, it should inform you that the
pre-test completed successfully. (If it didn't, cancel everything and do
not continue encrypting things! Try again.) If the pre-test went fine,
click Encrypt to start the encryption process. VC will give you a progress
bar and an estimated time to completion. As far as I know, you can keep using
the computer whilst this is happening (it may slow down the process, but only
slightly).
When the encryption has completed, restart and you should be greeted with the
VC password prompt. (If you aren't, follow the steps in the rescue
instructions along with the rescue disk.)
Enter your password, if you didn't specify a PIM, leave the field empty (hit
return/enter again), and your Windows system should boot normally.

Congratulations, that's the first part done! :-)
Arch Linux Encryption Setup and Install

Although this section/chapter is also titled "Install", it will mostly describe
how to set up the second hard drive for an encrypted Arch Linux installation. It
will also briefly cover the base install of Arch Linux, but details on good
practices or common post-install configurations are beyond the scope of this
guide.
Overview


First, we will be partitioning the second drive to create 3 partitions: /
(root), /home, and /swap.
Then, we will encrypt each of these partitions using LUKS. This is to ensure
no single password unlocks all the sensitive data in the system (although I
will tinker with that later).
With the root partition mounted, we will create a keyfile which will be used
to unlock the /home partition, so as to avoid having to enter more than one
password at boot (this kind of defeats the point of the previous bullet point,
so you can choose to skip that if you don't mind the two password prompts).
With every partition mounted, we will then install Arch Linux and chroot into
the new install. Here, we will set up a number of things such that the system
is able to boot, unlock, and mount our encrypted partitions.
Once this has been done, we will install rEFInd to have a pretty EFI boot
loader which can load both operating systems.

Partitioning


Start off by finding the disks available using the fdisk -l command.
Identify the hard drive without Windows installed on it and make a note of
its path (if you're using SCSI hard drives, it will be something like
/dev/sda; if you're using NVMe hard drives, it will be something like
/dev/nvme0n1).


Start fdisk on the hard drive using fdisk /path/to/drive.


In fdisk, press g to create a new GPT (unless you used the drive for
the shared partition, in which case, skip to the next point; the drive already
contains a GPT).


We will be using the existing Windows EFI boot/system partition (ESP), so
there is no need to create a new one.


Create the root partition.

Press n to start creating a partition.
Accept the default partition number or set a custom one if you know what you
are doing.
Accept the default start sector.
Indicate the desired size, e.g. +23G for 23GiB.


Create the swap partition.

Press n to start creating a partition.
Accept the default partition number or set a custom one if you know what you
are doing.
Accept the default start sector.
Indicate the desired size, e.g. I typically use 1.5xRAM so for 8GB of RAM I
would type +14G


Create the home partition.

Press n to start creating a partition.
Accept the default partition number or set a custom one if you know what you
are doing.
Accept the default start sector.
Accept the default end sector to use up the remainder of the available space
or specify a size if you do not wish to use up the remainder of the
available space.


Confirm that the layout looks correct by pressing p.

If it doesn't, press q to discard the changes and then start again.


Save/Write the changes to the disk by pressing w. This should also quit
fdisk.


Double-check that the changes were correctly applied by typing fdisk -l, you
should see the drive, now with the partitions listed as well.


(Sources: AW: Partitioning#Discrete partitions)
Encrypting


I will be using the Whirlpool hash algorithm and the Camellia cipher for some
of the encryption. This is in part due to a combination of paranoia and not
using the "common" algorithms and ciphers. However, both should be perfectly
secure, as they were selected for the NESSIE project (a European project
similar to the NIST AES). As mentioned previously, AES has dedicated
instructions on most modern CPUs, so if read and write speed is of utmost
importance, aes-xts-plain64 is probably the way to go.


In order to be able to use Camellia and WP, load their respective kernel
modules (you can get a list of all supported crypto kernel modules by running
ls /lib/modules/**/kernel/crypto)

modprobe camellia_generic
modprobe wp512


Encrypt the root partition using your desired cipher and hash algorithm (omit
them from the command to use the defaults) by running
cryptsetup --cipher <cipher> --hash <hashalg> --key-size <ks> luksFormat /dev/<sdxN>

Replacing <cipher>, <hashalg>, <ks>, and <sdxN> as appropriate. It
will ask you to confirm the action (double check that you've specified the
correct partition at this point) and to enter a password. Make sure it's
memorable, as this is the password you will be entering when booting the
system.

E.g. if you want to use the AES cipher and the default hash algorithm, with
a key size of 512, and your root partition is /dev/sda2, you would run
cryptsetup --cipher aes-xts-plain64 --key-size 512 luksFormat /dev/sda2


E.g. if you want to use the Camellia cipher and the WP hash algorithm, with
a key size of 256, and your root partition is /dev/sda2, you would run
cryptsetup --cipher camellia --hash whirlpool --key-size 512 luksFormat /dev/sda2


Encrypt the swap partition using your desired cipher and hash algorithm. Since
speed is fairly important on a swap partition, I will be using AES. You could
of course use something different. (Note: after writing this, I later noticed,
on a VM, that systemd sometimes hangs when trying to mount the encrypted
swap. This is registered as an issue on the systemd github, and seems to
possibly be due to a race condition. YMMV, but rebooting seems to
"toss the coin again" and fix things most of the time. If this is too much of
a hassle/too risky for you, then I fully understand and you can skip the
encryption of the swap partition and instead set up a regular, unencrypted
swap partition).
cryptsetup --cipher aes-xts-plain64 --key-size 256 luksFormat /dev/<sdxN>

Where /dev/sdxN is your swap partition. Again, set a password you can
remember (we need it to mount the swap initially).


Encrypt the home partition using your desired cipher and hash algorithm. Set
a memorable password because you will either need it to mount the home
partition each time or as a backup in case your keyfile gets lost (more on
this later).


Once all of the partitions have been encrypted, open each one of them by
typing
cryptsetup open /dev/<sdxN> <name>

and entering the password you set when prompted.

Replace <sdxN> as appropriate and giving the opened volume a sensible name,
e.g. I will be using cryptroot, cryptswap, and crypthome for the root,
swap, and home partitions respectively.


Each of the volumes should now be listed under their names in /dev/mapper
(you can check with ls /dev/mapper).


(Sources: AW: Kernel module#Manual module handling,
AW: Encrypting an entire system#LUKS on a partition,
AW: Swap Encryption)
Highly recommended: Backup the LUKS headers


If the LUKS headers get damaged somehow, this is equivalent to forgetting the
password or damaging/destroying the keyfile. I.e. your data will be
permanently encrypted without a way to access it. Therefore, it is highly
recommended to backup the LUKS headers. (This can be done at any point, so you
can continue with the setup and come back to this if you want/need).
If you have a USB drive or an external hard drive, plug it in, find its device
using lsblk, and mount it somewhere, e.g. /mnt/backup (you will probably
have to mkdir /mnt/backup first).
Backup the LUKS header using
cryptsetup luksHeaderBackup /dev/<sdxN> --header-backup-file /mnt/<backup-point>/<filename>.img

replacing <sdxN> with your external device, <backup-point> with where you
mounted the external drive, and <filename> with a name for the header backup
file.

(Sources: AW: Device encryption#Backup and restore)
Formatting and Mounting


Formatting the LUKS volumes is done exactly the same as you would for a
regular partition, e.g. (using my naming scheme for the volumes)
# mkfs.ext4 /dev/mapper/cryptroot
# mkfs.ext4 /dev/mapper/crypthome
# mkswap /dev/mapper/cryptswap

(a hash indicates a new command line in the prompt, it is not part of the
command)
Once all the volumes have been formatted, mount them:

Mount the root volume first
mount /dev/mapper/cryptroot /mnt


Make the directories /mnt/home and /mnt/boot for mounting the home and
ESP partitions to respectively, i.e. run
# mkdir /mnt/home
# mkdir /mnt/boot


Mount the home volume
mount /dev/mapper/crypthome /mnt/home


Mount the swap volume
swapon /dev/mapper/cryptswap


Mount the Windows ESP (if you've forgotten where it is, find it with
fdisk -l)
mount /dev/<sdxN> /mnt/boot


(Sources: AW: Installation Guide#Format the partitions,
AW Installation Guide#Mount the file systems,
AW: Encrypting an entire system#Mounting the devices)
OPTIONAL: Set up a keyfile for /home


If you want /home to be mounted automatically on boot, one option is to use
a keyfile. This section takes you through the setup for that. The keyfile will
be stored on the root partition, meaning it will not be possible to mount the
/home partition without knowing the password to the root partition or the
password set up when encrypting the /home partition (you could discard this
if you wanted, I will be keeping it but I will also supply the instructions
for deleting it).

Of course, if you are fine with entering two passwords on boot (it is probably
also more secure to not have /home automount), then you can skip to the next
section.
Create a place to store the keyfile, e.g. mkdir -p /mnt/etc/keyfiles
Create a keyfile of 2048 random bytes of data using
dd bs=512 count=4 if=/dev/random of=/mnt/etc/keyfiles/<my-keyfile> iflag=fullblock

replacing <my-keyfile> as appropriate (e.g. call it home-keyfile)

Note: If you wanted to create a keyfile of 4096 random bytes instead, you
would set count=8


Add the keyfile as a valid key to the crypthome volume (using the example
location and name from above)
cryptsetup luksAddKey /dev/<sdxN> /mnt/etc/keyfiles/home-keyfile

replacing <sdxN> with your home partition. Enter the password you used to
set up the volume when prompted.
OPTIONAL: If you do not want to keep the old password after setting up the
keyfile, it can be deleted. Personally, I would keep it in case something
happens to the keyfile or you need to open the volume without having access
to/without opening the root volume, but it's up to you.

If you want to remove the password used when setting up the volume, type
cryptsetup luksRemoveKey /dev/<sdxN>

and enter the password you want to remove.

(Sources: AW: Device encryption#Keyfiles,
AW: Device encryption#Removing LUKS key)
Install Arch


Now that we have our partitions mounted, we can finally get round to
installing Arch.
Edit the mirrorlist (found at /etc/pacman.d/mirrorlist) using a text editor,
e.g. nano, to contain a number of mirrors near you.
Install Arch by running
pacstrap /mnt base nano linux-hardened linux-firmware grub efibootmgr

(I'm using the linux-hardened kernel due to this being a security-focused
install. More details about kernel hardening can be found here).

If you require other packages like base-devel or vim simply add them to
the list.
Generate the list of devices to mount at boot
genfstab -U /mnt >> /mnt/etc/fstab


Make a note/Take a picture of the output of the following commands:
# ls -l /dev/disk/by-id
# lsblk -f


Chroot into the new system
arch-chroot /mnt


(Sources: AW: Installation Guide, AW: Security#Kernel hardening)
Essential setup


Now that we're chrooted into the new system, follow the
configuration part of the Installation Guide and set up the timezone,
clock, locale(s), hostname, hosts, etc...


Edit the /etc/crypttab file using a text editor, e.g. nano, to contain the
following lines:

An entry to mount the home partition (replacing <dev-uuid> with the UUID
of the actual device, not the LUKS volume, and crypthome with
whichever name you gave your encrypted home volume):
crypthome    UUID=<dev-uuid>    /etc/keyfiles/home-keyfile

if you set up a keyfile for the home partition

--- OR ---
crypthome    UUID=<dev-uuid>

if you didn't set up a keyfile and want to be prompted for the password
If you set up an encrypted swap, an entry to mount that (we are using
/dev/disk/by-id because of
persistent swap naming issues;
relplace cryptswap with whichever name you gave your encrypted swap
volume):
cryptswap    /dev/disk/by-id/<dev-id>    /dev/urandom    swap,cipher=aes-cbc-essiv:sha256,size=256

This will re-encrypt the swap partition with a random password each time,
rendering it unrecoverable once powered off. Since swap is not meant to be
persistent, this is fine and/or actually desirable. The default is to use
aes-cbc-essiv as the cipher, and a key size of 256 bytes. You can of
course customise these to fit your needs.

(A side note: If you are using a GPT-formatted drive, you can assign the
partition a persistent label at the GPT level using parted. I believe you
can exit the chroot, assign this, and chroot back, but you may have to
unmount and close the volume first. Start parted on the disk, then type
name <part-number> <name>, replacing <part-number> and <name> as
appropriate. You can then use the respective /dev/disk/by-partlabel/
entry instead of the /dev/disk/by-id/ entry).


Edit the /etc/fstab file using a text editor, e.g. nano.

Change the line concerning /dev/mapper/cryptswap to use that path instead
of the UUID (which will be changing on each reboot), i.e. the entry should
look something like:
# /dev/mapper/cryptswap
/dev/mapper/cryptswap    none    swap    defaults    0 0


(note: I don't know if this is specific to the VM I was testing this on or if
something has changed with the Arch ISO, but double-check dhcpcd is
installed using pacman -Qs dhcpcd. If it returns nothing, install it with
pacman -S dhcpcd (it is required for internet access). Aditionally, if you
need Wi-Fi access, installing iw and wpa_supplicant is probably a good
idea.)


Install GRUB
grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=GRUB


(Sources: AW: Installation guide#Configure the system,
AW: System configuration#crypttab, AW: fstab,
AW: GRUB#Installation)
Boot manager setup


Edit /etc/mkinitcpio.conf using a text editor, e.g. nano

Change the line beginning with HOOKS= in accordance with
this Arch Wiki page, i.e. it should read
HOOKS=(base systemd autodetect keyboard sd-vconsole modconf block sd-encrypt filesystems fsck)


Generate initramfs images by running
mkinitcpio -p linux-hardened


Configure GRUB

Generate the default config file by running
grub-mkconfig -o /boot/grub/grub.cfg
Change the kernel parameters by editing /etc/default/grub

Edit the line with GRUB_CMDLINE_LINUX to end with
rd.luks.name=<root-device-uuid>=cryptroot root=/dev/mapper/cryptroot

replacing cryptroot with whichever name you gave your root volume
Uncomment the line with GRUB_ENABLE_CRYPTODISK


Then re-generate the GRUB config using grub-mkconfig -o /boot/grub/grub.cfg

(Sources: AW: Encrypting an entire system#Configuring mkinitcpio,
AW: mkinitcpio#Common hooks,
AW: GRUB#Generate the main configuration file,
AW: GRUB#Additional arguments)
Reboot


Leave the chroot by typing exit
Unmount everything
# umount -R /mnt
# swapoff /dev/mapper/cryptswap


Close the encrypted volumes
cryptsetup close <volume-name>

(repeat for each of the volumes)
Restart by typing reboot and remove the Arch ISO USB when the machine starts
restarting.
You should be able to boot into Arch using GRUB.

If systemd gets stuck on mounting the swap partition, try restarting. It
should fix itself.
If you cannot boot at all, plug the Arch ISO USB back in and re-open and
mount everything; grab the outputs from lsblk -f, ls -l /dev/disk/by-id,
and ls -l /dev/disk/by-partlabel/; chroot; sanity-check your
/etc/fstab and your /etc/crypttab; sanity-check your /etc/mkinitcpio
and if you make changes to it, remember to re-run
mkinitcpio -p linux-hardened; and potentially also sanity-check
/etc/default/grub and re-generate the GRUB config using
grub-mkconfig -o /boot/grub/grub.cfg.


Install rEFInd


(note: if you do not want to install rEFInd but instead use GRUB, see
this section of the GRUB Arch Wiki page for details on how to detect the
Windows OS)
Once you are booted back into Arch (the install, not the ISO/live
environment)
Install rEFInd by typing pacman -S refind-efi
Run the refind-install script, it should correctly find the /boot
partition.
You should now have rEFInd installed at /boot and it should have created a
refind_linux.conf
When you reboot, you should now be greeted with the rEFInd boot manager and
able to boot both Windows and Linux.
At this point, I believe it's safe to uninstall GRUB, remove it from the
/boot/EFI directory, and delete the /boot/grub directory (all of which I
would do to save space on the ESP). However, if you want to keep GRUB there,
that is also a possibility (it may be a security risk, I'm not sure though).

(Sources: AW: rEFInd)
Accessing the shared partition from Linux


To access the shared partition from Arch, we will need VeraCrypt. It can be
installed through
pacman -S veracrypt


Then, the volume can be mounted to a mount point using
veracrypt /dev/<crypt-device> /mnt/<mountpoint>

replacing <crypt-device> with the device containing the shared partition (if
you are uncertain which one it is, find it with lsblk) and replacing
<mountpoint> with wherever you wish to mount the volume.

Done.

Congratulations on making it to the end, I know this was long and complicated,
especially if you've never done anything like this before. I hope it was
helpful and that you learned a thing or two :-)
Sources


https://www.reddit.com/r/linux/comments/9galhz/creating_a_hardened_arch_linux_installation_with/
https://wiki.archlinux.org
https://wiki.archlinux.org/index.php/Installation_guide
https://gist.github.com/CodingCellist/05556e0cb6cde146fc3f70b578b73da3
https://veracrypt.fr
https://www.howtogeek.com/fyi/you-cant-trust-bitlocker-to-encrypt-your-ssd-on-windows-10/
https://www.youtube.com/watch?v=eRuca6eAdFM
https://www.microsoft.com/en-us/windows/compare-windows-10-home-vs-pro
https://github.com/th-wilde/veracrypt-w10-patcher
https://wiki.archlinux.org/index.php/Partitioning#Discrete_partitions
systemd/systemd#12383
systemd/systemd#10179
https://wiki.archlinux.org/index.php/Kernel_module#Manual_module_handling
https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#LUKS_on_a_partition
https://wiki.archlinux.org/index.php/Dm-crypt/Swap_encryption
https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption#Backup_and_restore
https://wiki.archlinux.org/index.php/Installation_guide#Format_the_partitions
https://wiki.archlinux.org/index.php/Installation_guide#Mount_the_file_systems
https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Mounting_the_devices
https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption#Keyfiles
https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption#Removing_LUKS_keys
https://wiki.archlinux.org/index.php/Security#Kernel_hardening
https://wiki.archlinux.org/index.php/Installation_guide#Configure_the_system
https://wiki.archlinux.org/index.php/Dm-crypt/Swap_encryption
https://wiki.archlinux.org/index.php/Dm-crypt/System_configuration#crypttab
https://wiki.archlinux.org/index.php/Fstab
https://wiki.archlinux.org/index.php/GRUB#Installation_2
https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Configuring_mkinitcpio
https://wiki.archlinux.org/index.php/Mkinitcpio#Common_hooks
https://wiki.archlinux.org/index.php/GRUB#Generate_the_main_configuration_file
https://wiki.archlinux.org/index.php/GRUB#Additional_arguments
https://wiki.archlinux.org/index.php/GRUB#Detecting_other_operating_systems
https://wiki.archlinux.org/index.php/REFInd