On 26/09/2019 23:27, Robert Nichols wrote: > I wasn't even thinking of trim pass-through. I routinely set up VMs > with space allocations that, in total, exceed the space available on > the host. Such VMs cannot use authenticated encryption since they > would have to immediately use all of their allocated space. I also > routinely save system images with partclone or clonezilla, > specifically to avoid saving the content of the free space in the > filesystems. Such an image would fail authentication when restored. > These are fairly common practices. LUKS2 authenticated encryption > should come with huge warnings. I do not quite well understand your complaint. LUKS2 is just on-disk format, it is much more flexible, and allows some new features like integrity protection, but nobody forces you to use that. Default options are precisely the same as in LUKS1, and you can still use LUKS1 if you prefer it. Actually, even the authenticated encryption does not need to wipe the space in principle. It is a workaround to avoid bugs (to avoid reading areas that were never written). You can skip it if your environment is doing IO operations correctly. TRIM passthrough is in some situations complicated, so it is not yet supported for authenticated encryption (dm-integrity backed devices). It is just missing a feature, that can be implemented later. A full device wipe is present in many other systems - VeraCrypt by default does it; Debian installer wipes LUKS devices by writing random data to it. And these systems use just length preserving encryption. A common practice is to TRIM the device to free unused space. We are missing better documentation of common use cases and limitations. I am well aware of that, but sometimes things take longer than expected, sorry for that. Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
