On 16 Dec 2019 11:24 -0700, from lists@xxxxxxxxxxxxxxxxx (Chris Murphy): > In place conversion can be better supported in more sophisticated > environments. Linux installers are already overly complicated and soak > limited resources maintaining them Opting into encryption right now > essentially requires either installer support or the burden of backup > restore. That's not great choices. And what installers provide an ATA > Secure Erase or Sanitize option? I don't know of any. I don't know about current Mac OS X, but Windows has it far easier. They only support two (three if you count ReFS) file systems, and IIRC only NTFS can be used on the system partition. An in-place conversion from unencrypted to encrypted can be developed and tested _relatively_ painlessly when you basically only need to support _one_ format within the encrypted container, whether the container format is called LUKS or BitLocker or something else. Contrast this to LUKS on Linux, which can be used with anything from no file system at all to file systems you might not have even heard of. Okay, it's probably fairly simple to do an in-place conversion of a container that contains just an ext4 file system, and it's probably a reasonable first step since ext4 is so commonly used. What if what's in the container is a part of a volume group? What if it's a part of a MD RAID array? What if it's a part of a Btrfs file system? A part of a ZFS vdev? (In the case of the latter two, either mirrored or RAID5/6-esque.) Or XFS? How about a squashfs? And that's just to list a few. And that's before we consider people potentially doing crazy things like putting a LUKS container inside a LUKS container. Or people who still use LILO. Sure, for some of those, you might say "we don't need to cater to those cases for online migration from unencrypted to encrypted". But that, too, is drawing a largely arbitrary line somewhere. What says one thing goes on one side of that line, and another goes on the other side, except someone's say-so? The seemingly obvious solution indeed is to have an unencrypted LUKS container pre-prepared, at which point it's possible to do at least an offline reencryption in-place with current tools. But then the issue indeed becomes that you've got metadata that indicates you've got something which is normally encrypted, except in this one case where it isn't. That seems likely to trip at least a moderate number of people up because they'd look, see LUKS, and conclude that their data is protected, when in fact it isn't. Every tool that identifies something as a LUKS container would, at a minimum, need to peek into it to identify the "unencrypted LUKS" special case to protect against this. Which again is much easier when you control the entire operating system, including the system software. > Conversely, Windows and macOS use comparatively brain dead installers > (very simplistic UI, perhaps a few choices at most, pretty much > amounting to point at a target and push a button). Easy to install. > Easy to make the encryption decision later without the penalty of > backup restore. Perfectly secure encryption? I don't know. But the > barrier to entry is low. I don't think I'd call the Windows installer "brain dead". Simplified, yes, but that's not the same thing. They hide a lot of the complexity which of course also means that when you _do_ have a legitimate need to do something out of the ordinary, you generally can't. There are Linux distributions with installers that aren't a great deal more complex than the Windows installer, especially if you go for the "simple" installation. Of course, if you take a distribution that's already geared toward power users, and use its advanced installation mode, you're going to be presented with a lot of choices, but only because you asked to be. As for backups; encryption increases the risk of data loss. I don't know off hand how long you've been on the list, but it happens usually a few times per year that someone asks how to recover their data because they can't open the LUKS container normally. _People in general don't have backups. My experience is that even fairly technically savvy people often don't have backups._ By adding encryption, especially with something like LUKS' anti-forensic properties, you (general "you") are increasing the risk of data loss quite significantly, because you go from what would otherwise be a trivial problem to making the same situation a catastrophic problem. I'm not a fan of scary UI messages, but I do feel that that _should_ come with big warning labels, so that the user is at least _aware_ of what they are doing and its implications. -- Michael Kjörling • https://michael.kjorling.se • michael@xxxxxxxxxxx “Remember when, on the Internet, nobody cared that you were a dog?” _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
