From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Fri, 13 Dec 2019 19:55:07 +0100 (CET) Received: by mail-wm1-x331.google.com with SMTP id t14so59827wmi.5 for ; Fri, 13 Dec 2019 10:55:06 -0800 (PST) MIME-Version: 1.0 References: <2b1f731d-0713-fadf-f895-b62b00363a95@gmail.com> In-Reply-To: <2b1f731d-0713-fadf-f895-b62b00363a95@gmail.com> From: Chris Murphy Date: Fri, 13 Dec 2019 11:54:48 -0700 Message-ID: Content-Type: text/plain; charset="UTF-8" Subject: Re: [dm-crypt] LUKS2 support for null/plaintext target List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Milan Broz Cc: Chris Murphy , dm-crypt@saout.de On Fri, Dec 13, 2019 at 7: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?!) 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