TODO: make "discard" in cryptsetup and filesystems optional

[HidingCherry]

The discard option is evil for any encryption - I enabled it for a smaller VM image footprint. fstrim needs discard on cryptsetup open and it needs the filesystem to be mounted with the discard option.

[HidingCherry]

https://wiki.archlinux.org/title/Dm-crypt/Specialties#Discard/TRIM_support_for_solid_state_drives_(SSD) add a warning

[MartinX3]

https://wiki.archlinux.org/title/Dm-crypt/Specialties#Discard/TRIM_support_for_solid_state_drives_(SSD) Advantages of using trim/discard:

• By default the LUKS header is stored at the beginning of the device and using TRIM is useful to protect header modifications. If for example a compromised LUKS password is revoked, without TRIM the old header will in general still be available for reading until overwritten by another operation; if the drive is stolen in the meanwhile, the attackers could in theory find a way to locate the old header and use it to decrypt the content with the compromised password.
• If plausible deniability is not required, TRIM can be used for its performance gains, provided that the security dangers described at the top of this section are not of concern.
• Most SSDs support the ATA_TRIM command for sustained long-term performance and wear-leveling.
  • https://wiki.archlinux.org/title/Solid_state_drive#TRIM

[HidingCherry]

* `By default the LUKS header is stored at the beginning of the device and using TRIM is useful to protect header modifications. If for example a compromised LUKS password is revoked, without TRIM the old header will in general still be available for reading until overwritten by another operation; if the drive is stolen in the meanwhile, the attackers could in theory find a way to locate the old header and use it to decrypt the content with the compromised password.`

I read somewhere that luksRemoveKey would overwrite the to-be-removed-key several times with random data - thus this isn't really needed. Sadly no source for that, I read that ages ago, I have not found this again.

* `If plausible deniability is not required, TRIM can be used for its performance gains, provided that the security dangers described at the top of this section are not of concern.`

Valid reasoning e.g. if the drive is not in your posession, so you can't destroy it in case of failure - otherwise the drive wouldn't need to be encrypted. (Just hypothetical - not gonna discuss this.)

* `Most SSDs support the ATA_TRIM command for sustained long-term performance and wear-leveling.`

We cannot confirm a correct function of wear-leveling, this is out of our control. Not gonna discuss this, otherwise we could question god here.