Re: [dm-crypt] LUKS2 support for null/plaintext target

[Chris Murphy <lists@colorremedies.com>]

On Fri, Dec 13, 2019 at 7:59 AM Milan Broz <gmazyland@gmail.com> 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