On Sat, Dec 14, 2019 at 7:45 AM Arno Wagner <arno@xxxxxxxxxxx> wrote: > > On Sat, Dec 14, 2019 at 05:28:31 CET, Robert Nichols wrote: > > On 12/13/19 8:59 AM, Milan Broz wrote: > > >Hi, > > > > > >On 07/12/2019 00:10, Chris Murphy wrote: > > >>I'm wondering if it's possible, or LUKS2 could be extended, to support > > >>an non-encrypted target. That is, the virtual device and backing > > >>device would contain the same information. > > > > > >(You are not the first one asking for support for this option.) > > > > > >In fact, the support is already there. But I am reluctant to officially > > >support it for a very long time, because it would be super confusing > > >for users (We have LUKS, but actually no encryption?!) > > > > How about using real encryption but use /dev/null as the key-file? > > (Just a thought.) > > I can see some nice failure modes with that, e.g. with accidentally > empty key files. > > I am also not sure what the use-case of the whole thing is > besides benchmarking and debugging as Milan said. > > If you want to put evertyhing in place, but do not encrypt (yet) > so you can just encrypt data in place later, this may be the wrong > approach. I reccomend (and I think that is in the FAQ) to do a > backup, wipe the data and make a LUKS container and then to restore > that backup. Doing this without backup is dangerous anyways. > > I think this may not have a good solution and we should default to > "secure" here. There are far too many security issues today that > come from people having selected "convenient" instead. Having some > way to do this that is not too convenient or obvious is fine. I don't know how it works with APFS (Apple File System) today, but up until a couple years ago when Apple was still using JHFS+ and Core Storage (their logical volume manager, with nearly the same terminology as LVM), they had a live migration between unencrypted (default installations) and encrypted. The user could even shutdown and reboot during the conversion. Based on observation, not any detailed analysis, the original state out of the box has no encryption, and no Core Storage. It's a plain GPT partition, using an HFS+ type code, and an ordinary journaled HFS+ volume. Upon enabling encryption, I surmise based on the before, during, and after states on disk, that the HFS+ volume is slightly shrunk (perhaps ~100MB, I'm guessing based on years of memory recall here so take it with a grain of salt), and a bunch of Core Storage metadata is written in that space, the original partition is changed into a Core Storage partition in the GPT, while also presumably becoming a PV (physical volume). And the conversion is maybe something like a pvmove --atomic where the unencrypted extents are encrypted and written elsewhere, while continuously expanding the encrypted PV and shrinking the encrypted one. >From a user perspective, they're informed the encryption conversion status is progressing with some time estimate to completion. The before state on disk is clearly not encrypted, and the conversion state is both in the GUI and CLI commands, also clearly stated to be in a state of conversion and also it indicates which direction the conversion is happening: encrypting or decrypting, since it's possible to completely reverse this. Also, while they have all the same PV, VG, LV terms, they also have an LF (logical family) layer which is functionally inserting a LUKS layer as an attribute to an LV. i.e. encryption is an integrated function of Core Storage. So that's as a point of comparison what I think people are after is that kind of use case, where LUKS2 already offers a live re-encryption, but not an easy way to opt into it if it's not already encrypted. You'd have to do a monolithic, offline, backup, setup encryption, and restore. It's a bit tedious and requires some expertise to do that, rather than the experts inventing a thing so users can just push a button. The more regular users are left out of this, I think the better, not merely for their convenience, but so that they aren't f'g things up. A huge amount of data loss is user induced. I'm certainly on board the argument of keeping things simple as it pertains to the LUKS2 format, and not conflate either plaintext/pseudo-ciphertext with a volume that has metadata suggesting very clearly it's ciphertext. But I'm likewise not on board with the idea of avoiding user convenience, because that is when they make mistakes. And if it's left to people only a little more sophisticated than I am to invent something, that's when security mistakes get made, somehow having left some unencrypted residue behind or otherwise leaked some information. The impetus behind an Apple or Microsoft doing things this way, of course they don't want users having to do a monolithic backup and restore offline to get to an encrypted state. Users would sooner do without it. And they don't want to recommend a reinstallation of the OS to get there either for the same reason. Whereas on most Linux distros this question is asked at install time. But that's often not when the user has thought about whether or not that applies to their use case, and opts for no encryption, and later realizing that their chance is lost with a high burden to encrypt, they forego it. And now some distributions either default to encryption enabled, or are discussing it, with various degrees of consequences (the keyboard layout problems, and whether the LUKS passphrase really is properly considered user domain at all). -- Chris Murphy _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
