From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from vps344433.stocktonflats.co.uk (vps344433.stocktonflats.co.uk [164.132.228.222]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Fri, 7 Jun 2019 10:57:35 +0200 (CEST) Received: from mail-qk1-f174.google.com (mail-qk1-f174.google.com [209.85.222.174]) by vps344433.stocktonflats.co.uk (Postfix) with ESMTPSA id 7D4C63E8A0 for ; Fri, 7 Jun 2019 10:57:23 +0200 (CEST) Received: by mail-qk1-f174.google.com with SMTP id d15so768198qkl.4 for ; Fri, 07 Jun 2019 01:57:23 -0700 (PDT) MIME-Version: 1.0 References: <20190522124652.GA1205@tansi.org> <20190522171614.GA23632@fripost.org> <20190529134345.GA3251@fripost.org> In-Reply-To: <20190529134345.GA3251@fripost.org> From: Dominic Raferd Date: Fri, 7 Jun 2019 09:56:52 +0100 Message-ID: Content-Type: multipart/alternative; boundary="000000000000cac0b6058ab80412" Subject: Re: [dm-crypt] LUKS + dm-crypt Debian/Ubuntu expanding encrypted root LV onto 2nd disk List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de --000000000000cac0b6058ab80412 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This is still work in progress for me but I give my interim response below. Thanks for all the help. On Wed, 29 May 2019 at 14:44, Guilhem Moulin wrote: > On Wed, 29 May 2019 at 12:26:12 +0100, Dominic Raferd wrote: > > Thanks but I am using the standard Debian recipe (via Ubuntu alternate > > installer which uses anaconda) for drive encryption (LUKS + dm-crypt, > with > > LVM on top) and this does not give any chance (AFAIK) to specify a > special > > parameter for cryptsetup. > > That flag is to be passed to `open` (or `refresh`) at initramfs stage, > not `luksFormat` at d-i stage. I suppose it doesn't change much though, > as --disable-keyring, and --token-* flags can't be specified to Debian's > crypttab(5) at the moment. > You raise my hopes and then dash them ;-) > > > The idea of reusing key from first crypt device when creating second > crypt > > device is that once the first crypt device is decrypted in initramfs (b= y > > user entering password) then the second one can be decrypted using the > key > > from the first. > > You have a backup key slot on the device unlocked with decrypt_derived, > right? Otherwise you'll loose both devices if the source is lost or > damaged. > I am only testing now but what you say is wise. > As written in /usr/share/doc/cryptsetup-initramfs/README.initramfs.gz > decrypt_derived doesn't work with LUKS2 on Linux =E2=89=A54.10, because t= he > volume key of the source device is offloaded to the kernel keyring thus > not readable by userspace. Since --disable-keyring can't be > persistently written into the LUKS header as of 2.1.0, nor can it be > toggled from crypttab(5), I guess that if you want to stick to > decrypt_derived your options are to use `luksFormat --type luks1` (or `co= nvert > --type luks1`); unfortunately this doesn't work. I try it (booting from SystemRescueCD): # cryptsetup convert /dev/sda5 --type luks1 WARNING! =3D=3D=3D=3D=3D=3D=3D=3D This operation will convert /dev/sda5 to LUKS1 format. Are you sure? (Type uppercase yes): YES Cannot convert to LUKS1 format - keyslot 0 is not LUKS1 compatible. ... --000000000000cac0b6058ab80412 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

This is still work in progress for me b= ut I give my interim response below. Thanks for all the help.
<= div dir=3D"ltr" class=3D"gmail_attr">
On Wed, 29 May= 2019 at 14:44, Guilhem Moulin <guilhem@fripost.org> wrote:
On Wed, 29 May 2019 at 12:26:12 +0100, = Dominic Raferd wrote:
> Thanks but I am using the standard Debian recipe (via Ubuntu alternate=
> installer which uses anaconda) for drive encryption (LUKS + dm-crypt, = with
> LVM on top) and this does not give any chance (AFAIK) to specify a spe= cial
> parameter for cryptsetup.

That flag is to be passed to `open` (or `refresh`) at initramfs stage,
not `luksFormat` at d-i stage.=C2=A0 I suppose it doesn't change much t= hough,
as --disable-keyring, and --token-* flags can't be specified to Debian&= #39;s
crypttab(5) at the moment.
You raise my hopes and then dash them ;-)=C2=A0

> The idea of reusing key from first crypt device when creating second c= rypt
> device is that once the first crypt device is decrypted in initramfs (= by
> user entering password) then the second one can be decrypted using the= key
> from the first.

You have a backup key slot on the device unlocked with decrypt_derived,
right?=C2=A0 Otherwise you'll loose both devices if the source is lost = or
damaged.

I am only testing now but what you say is wise.=C2=A0<= /div>
=C2=A0
As written in /usr/share/doc/cryptsetup-initramfs/README.initramfs.gz
decrypt_derived doesn't work with LUKS2 on Linux =E2=89=A54.10, because= the
volume key of the source device is offloaded to the kernel keyring thus
not readable by userspace.=C2=A0 Since --disable-keyring can't be
persistently written into the LUKS header as of 2.1.0, nor can it be
toggled from crypttab(5), I guess that if you want to stick to
decrypt_derived your options are to use `luksFormat --type luks1` (or `convert --type luks1`);=20
=
unfortunat= ely this doesn't work. I try it (booting from SystemRescueCD):

# cryptsetup convert /dev/sda5 --= type luks1

=
WARNING!
=
=3D=3D=3D=3D=3D=3D= =3D=3D
This ope= ration will convert /dev/sda5 to LUKS1 format.

Are you sure? (Type uppercase yes): YES
Cannot convert to LUKS1 form= at - keyslot 0 is not LUKS1 compatible.
...
--000000000000cac0b6058ab80412--