On Fri, Dec 13, 2019 at 7:59 AM Milan Broz <gmazyland@xxxxxxxxx> 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?!) I agree there is potential for confusion. And it might be out of scope for LUKS. When I do: # blkid I see a partition is TYPE="crypto_LUKS" and that's a fairly difficult statement of fact to overcome with a "yeah but it really isn't crypto, you should have run this other command that would tell you that". There is a valid argument that the crypto_LUKS signature should be trusted to mean the contents are in fact ciphertext,, and not pseudo-ciphertext trivially unlocked. > So, the first method: > you can always use cipher_null (and you must use empty passphrase in this case). > That variant should work already and it is intended for debugging/measuring dm-crypt > layer overhead (dm-crypt is used, but with the null cipher). > > The second variant is to directly use dm-linear target instead of dm-crypt, > and it is already used during online (re)encryption in one phase - when adding > encryption to not yet encrypted device. > You cannot format such a device initially this way. > > It is not so complicated to add support for this to format operation, > but ... I am still not sure. Any comments? In some sense the feature request is trying to make LUKS deal with two difficulties: 1. producing a standard everyone can agree on, because if LUKS doesn't do it, would anyone else follow it? 2. adding the necessary free space in front of the partition to be encrypted, the area that would be used for the LUKS header and padding The gotcha with 2. without LUKS taking on this role, is how ugly it ends up looking depending on what partition scheme is being used: a. GPT only: create an empty partition ~16MB, immediately before the intended plaintext partition that will be later converted (encrypted). Maybe it gets a unique magic, or a new partition type GUID, that describe it as "empty but intended for future LUKS-based encryption of the partition that follows" b. LVM LV? No idea. c. MBR? Similar to GPT? d. Files used on loop? Always use GPT, and follow the GPT guideline above. -- Chris Murphy _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
