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 ; Wed, 29 May 2019 13:27:05 +0200 (CEST) Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) by vps344433.stocktonflats.co.uk (Postfix) with ESMTPSA id D00283E882 for ; Wed, 29 May 2019 13:26:54 +0200 (CEST) Received: by mail-qt1-f181.google.com with SMTP id z19so1980478qtz.13 for ; Wed, 29 May 2019 04:26:54 -0700 (PDT) MIME-Version: 1.0 References: <20190522124652.GA1205@tansi.org> <20190522171614.GA23632@fripost.org> In-Reply-To: From: Dominic Raferd Date: Wed, 29 May 2019 12:26:12 +0100 Message-ID: Content-Type: multipart/alternative; boundary="000000000000f374be058a050e86" 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 --000000000000f374be058a050e86 Content-Type: text/plain; charset="UTF-8" On Wed, 29 May 2019 at 12:07, Ondrej Kozina wrote: > On 5/29/19 11:56 AM, Dominic Raferd wrote: > > Thanks Guilhem, those links are very helpful but I have not solved it > > yet. Another change in the new cryptsetup is LUKS2 and use of the kernel > > keyring, so when run from a booted system dmcrypt_derived just returns a > > message that the source crypt device uses the keyring - I don't know how > > to obtain the actual key to use it in the creation of the second crypt > > device (or maybe it is impossible > > Not sure why you need to reuse volume key put in dm-crypt exactly but if > you rely on the classical method, you may use --disable-keyring > parameter of cryptsetup. With this parameter cryptsetup uploads the key > in hexbyte representation as with LUKS1 format. > 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. Previously it used LUKS1 without keyring but now it uses LUKS2 with keyring. I want to keep the initial setup process as simple as possible (documented at https://www.timedicer.co.uk). 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 (by user entering password) then the second one can be decrypted using the key from the first. (Both devices must be decrypted in initramfs because root LV is based on a VG which spans *both* devices - a scenario that might arise if the first device runs out of space.) This way there is no need to enter password twice or to cache it. --000000000000f374be058a050e86 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, 29 May 2019 at 12:07, Ondrej Kozina <okozina@redhat.com> wrote:
On 5/29/19 11:56 AM, D= ominic Raferd wrote:
> Thanks Guilhem, those links are very helpful but I have not solved it =
> yet. Another change in the new cryptsetup is LUKS2 and use of the kern= el
> keyring, so when run from a booted system dmcrypt_derived just returns= a
> message that the source crypt device uses the keyring - I don't kn= ow how
> to obtain the actual key to use it in the creation of the second crypt=
> device (or maybe it is impossible

Not sure why you need to reuse volume key put in dm-crypt exactly but if you rely on the classical method, you may use --disable-keyring
parameter of cryptsetup. With this parameter cryptsetup uploads the key in hexbyte representation as with LUKS1 format.

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 crypts= etup. Previously it used LUKS1 without keyring but now it uses LUKS2 with k= eyring. I want to keep the initial setup process as simple as possible (doc= umented at https://www.timedicer.co= .uk).

<= /div>
The idea of reu= sing key from first crypt device when creating second crypt device is that = once the first crypt device is decrypted in initramfs (by user entering pas= sword) then the second one can be decrypted using the key from the first. (= Both devices must be decrypted in initramfs because root LV is based on a V= G which spans *both* devices - a scenario that might arise if the first dev= ice runs out of space.) This way there is no need to enter password twice o= r to cache it.
--000000000000f374be058a050e86--