On Mon, Dec 16, 2019 at 21:46:40 CET, Chris Murphy wrote: > 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. It is related to whether they have a backup procedure in place or not. If you find that irrelevant, then I really cannot help you. Doing any kind of partition or filesystem manipulation without a current, good backup is foolish at best and asking for data loss at worst. And no, I am not open to debate on this. > 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. Who are you answering to here? _My_ position is that the only way to securely erase an SSD is physical destruction. > >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 I reject your rejection entirely as well. It seems to me _you_ want to push something on users that they do not actually want or need. And you have presented exactly zero good arguments so far why people should encrypt. > 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. Excuse me? Since when is doing a backup and restore in any way "esoteric"? How much experience do you have with this "computing" thing? Also, what makes you think that in-place conversion can easily reach the level of resilience you assume it has? Getting there takes a _lot_ of testing and very defensive and careful coding and it may well have to include other layers than the one LUKS resides in. > > Given these two things, why on earth do you want these people > > to use encryption? > > I think these are weak arguments, Do you have any actual argument here? Because it does not seem you have any... > 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. How on earth can you call this an "unreasonable burden"? > The vastly stronger argument is: this is really hard to do and we > don't want to do it. Ok, I see you are not actually interested in any facts here, you just want to push your view. Even minimal standards of competent private IT operation do include backup and restore as standard operations. > Papering over that with unpersuasive security concerns, and making > assumptions about whether users backup or not, doesn't progress the > conversation. As does allowing exactly no progress except in the direction you are trying to force. And please stop the cheap propaganda language. It is insulting. And it convinces nobody. > > 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. Empty, unfounded claim. Why again do you want users to "opt in"? Oh, right, You did not say. > 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. I did not make that argument. > 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. And that is why I recommend physical destruction instead. Regards, Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- A good decision is based on knowledge and not on numbers. -- Plato If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
