On Mon, Dec 16, 2019 at 11:52 AM Arno Wagner <arno@xxxxxxxxxxx> wrote: > > On Mon, Dec 16, 2019 at 19:24:33 CET, Chris Murphy wrote: > [...] > > But consider that as a direct consequence of the burden to > > backup->luksFormat>restore, quite a lot of users opt out of encryption > > entirely. The point of in-place conversion isn't perfect security. > > It's to get more users to opt in, by reducing the penalty of opting > > in. > > But why would you _want_ users to "opt in"? It seems like entirely > the wrong thing to do to me. First consider that the users > you are talking about do not have backups. Hence their data must > be basically worthless anyways! First, this is a distraction and not relevant. It conflats confidentiality with integrity/availability of the data. That the data should be private/remain confidential is not related to it's long term value. Second, blkdiscard and fstrim can merely flag cells for erasure, or merely dereference LBAs. No assurance the cells are actually erased or when they will be erased. It's the same as the firmware passively determining cells can be marked for erasure upon LBA overwrite of an in-place conversion. Is it your position that only Security Erase, Security Erase Enhanced, or Sanitize avoid giving the user a false sense of security? In which case, now the procedure requires a complete wipe of the drive. And that means a fully offline process to conduct the restore until it is complete during which time the system is not usable. And it's extra burdensome for dual boot users, who must do two full reinstallations and restores of those two operating systems. >Second, their data is so little > in need of protection that something as simple and as a backup > already makes them do without encryption. Hence their data must > actually not be sensitive in any way! I reject the premise entirely. And it ignores users who have done a backup, who still have a significantly greater burden put on them through esoteric processes necessary to do encryption after the fact, and a monolithic restore from backup which prevents them from working until the restore is complete. That is not the case with in-place conversion - the system is completely transparently usable the entire time including reboots and shutdowns. > Given these two things, why on earth do you want these people > to use encryption? I think these are weak arguments, in addition to wholesale ignoring users who do backup who still have an unreasonable burden put on them by existing choices: install time encryption or post-install partition ninja and offline restore. The vastly stronger argument is: this is really hard to do and we don't want to do it. Papering over that with unpersuasive security concerns, and making assumptions about whether users backup or not, doesn't progress the conversation. > Security comes at a price. That price has to be paid. > No price - no security. There is _no_ way to fix this and trying > to do so only does damage to the user by making things too complex > for them to handle. The backup restore proposal is too complex, it's why users don't opt in now. It's why alternatives are being explored by downstreams. The argument that the user is at greater risk with an in-place conversion than backup restore, neither depending on prior Secure Erase or Sanitize but only depending on trim/discard, is not persuasive. Such preparation is not built-in for any distro installer with which I'm familiar, not even as an option let alone by default. Secure Erase is esoteric knowledge. I would be surprised if 1 in 1000 users has heard of it. -- Chris Murphy _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
