Debian install encrypted swap

LVs sit inside a Volume Group and form, in effect, a virtual partition. PE : Physical Extents. In order to manipulate the actual data, it is divided into blocks of data called P hysical E xtents. LE : Logical Extents. Similar to Physical Extents, but at the Logical Volume level. The size of blocks are the same for each logical volume LV in the same volume group VG.

To protect the confidentiality of your valuable data, for instance in the event of the loss or theft of your computer or storage, such as volume, solid state disk, or hard drive, when formatting a LVM volume it is suggested to consider formatting it using the encrypted LVM option.

If you choose the encrypted LVM option, it is suggested to consider creating backup passwords. So that recovery is quick and easy Otherwise it the event that somehow your password is not working, you risk permanently losing all your valuable data. It is surprisingly frequent that people lose all their data because somehow their password is no longer working, and they did not created backup passwords. Encrypted LVM is very strong, so if somehow you locked yourself out, unless you have backup passwords it is likely that you would be permanently locked out Backup passwords Creating backup passwords is a two steps process.

First you add backup passwords, second you backup those passwords. This number will identify which key-slot you want to edit. I certainly thought this was true and partitioned my Linux installs accordingly. However, turns out that GRUB2 supports booting from an encrypted boot courtesy of its cryptodisk module. Debian's installer does not provide the option of encrypting boot.

But it is possible! Installing LVM on top of the encrypted partition allows:. Debian installer creates LUKS2 devices. And of course, making low entropy passphrases twice as easy to brute-force.

There is a trade-off to be made here. You can reuse the existing passphrase in the above prompts. Note : cryptomount lacks an option to specify the key slot index to open. All active key slots are tried sequentially until a match is found. Run the following command to discover its index. This is because GRUB boots with the given vmlinuz and initramfs images, but there is currently no way to securely pass cryptographic material or Device Mapper information to the kernel.

Hence the Device Mapper table is initially empty at initramfs stage; in other words, all devices are locked, and the root device needs to be unlocked again. To avoid extra passphrase prompts at initramfs stage, a workaround is to unlock via key files stored into the initramfs image. Since the initramfs image now resides on an encrypted device, this still provides protection for data at rest.