Open inferenceus opened 1 year ago
The article Desktop Linux Hardening states disk encryption requires an OS reinstall if it was not enabled on first install. However, it is now possible to encrypt-in-place using cryptsetup's reencrypt feature (using --encrypt argument), which converts a currently unencrypted partition into a LUKS container. Although this approach does require a small amount of free space available at the end of the partition for the new LUKS header (applied using another argument), I have personally used this feature and it works as intended.
Despite the unencrypted data being leaked on the disk due to previously being written unencrypted, the same occurs with an OS reinstall without writing random data such as /dev/urandom when using a HDD, or impossible on an SSD without physical destruction (since ATA Secure Erase can't be trusted to have been implemented correctly without testing beforehand), so it shouldn't be an issue in this aspect.
Which filesystem does it work with? Does it work with XFS? Because afaik XFS cannot be shrunk, so how is one supposed to put the LUKS header in?
I used it with Btrfs. There is an argument (--reduce-device-size
) to automatically shrink the partition to allow the header to fit. I used --reduce-device-size 16M
for a 16 MiB shrink and the header fit there when running reencrypt --encrypt
.
The article Desktop Linux Hardening states disk encryption requires an OS reinstall if it was not enabled on first install. However, it is now possible to encrypt-in-place using cryptsetup's reencrypt feature (using
--encrypt
argument), which converts a currently unencrypted partition into a LUKS container. Although this approach does require a small amount of free space available at the end of the partition for the new LUKS header (applied using another argument), I have personally used this feature and it works as intended.Despite the unencrypted data being leaked on the disk due to previously being written unencrypted, the same occurs with an OS reinstall without writing random data such as /dev/urandom when using a HDD, or impossible on an SSD without physical destruction (since ATA Secure Erase can't be trusted to have been implemented correctly without testing beforehand), so it shouldn't be an issue in this aspect.