From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 04CB7C11F64 for ; Thu, 1 Jul 2021 16:00:45 +0000 (UTC) Received: from mail.server123.net (mail.server123.net [78.46.64.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5D24061417 for ; Thu, 1 Jul 2021 16:00:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5D24061417 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=smile.fr Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dm-crypt-bounces@saout.de X-Virus-Scanned: amavisd-new at saout.de Authentication-Results: mail.server123.net (amavisd-new); dkim=pass (2048-bit key) header.d=smile-fr.20150623.gappssmtp.com Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2a00:1450:4864:20::634; helo=mail-ej1-x634.google.com; envelope-from=yoann.congal@smile.fr; receiver= Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (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 ; Thu, 1 Jul 2021 17:57:48 +0200 (CEST) Received: by mail-ej1-x634.google.com with SMTP id bu12so11305328ejb.0 for ; Thu, 01 Jul 2021 08:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smile-fr.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wdutgTXRWE6UtqJPNXF93Tr/snMK9F5317Kl3gePw/w=; b=T8E8RkZZnMujvIaWnFQOo+haDeIjrDO0CjU9f7Y9T9H642Xyxej1p3eorOYRUqPOQz /5e+1ZdAJD9/0LocE4Ze+Ewk9BZ2rqq8ch4/9Clg42CR1hz7a/PuTBnmvsJhHfpRnccF 32w45qK36irbt2QIRBHnOsRoTxYmu6pYWC9kK+cy5bvtDt/qMbLwx+A7hOiIi5KZ4h8o MhnC8TGne5CimK3RLce3nO/UEaIwwWQCwj1ocIu/ab8zbwtSkca9Jw6VP8tCdbcrFpk1 a2E2mkfKQOAXcO1F989VjZ5YeAFnZclBV46889DeRyCqGBZPhAaIJx7Aqm7LRYTIRU0S OmCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wdutgTXRWE6UtqJPNXF93Tr/snMK9F5317Kl3gePw/w=; b=gn+LgKppzZUi53DYVwl83sE7Kur0ZXaHi7sHYSvruUPjsRl6UYyJsaAfUgpuDePX6M HFva0EMJNCADF0AWXGDpPlsu9Eu7Ydt+tYIBtLgWx0YsP4q7leW79iufkNBsZ4AiFiSj AYdTRXdZ+U9AlaQGjIY6/GAf25XTUZscRrqDvlY7lCu7bVZOvL+XHO/qgZotnbcY9Mk7 9rbcaoiK5rs3F6ajqsi+DYoPdCj6EvCUuowjCzMkxGVf4/qUHxaY+RwYJVEt0YznFBgg sZ2fvR5GmQxNFOf/EaxOmTRzgMmTqzMRMcDxXOguXA1jtoi17cQuyIIqsQaFvfctZ7PC SwhQ== X-Gm-Message-State: AOAM533KKo9QfHd2Fr54TwUYw1Q+7BxHWcGFnZ3e9TVaRiLsk0oGzrzV JL2T3aV0yFdtXUa6ICMFbP1RjOBrLegRVnUOZQB2lw== X-Google-Smtp-Source: ABdhPJwO17reTwv2aO8tUWmoINQBHCrzYPUa4njGhpunZauLKpF4FQCQGhjD5AaPbDnOGrrOkBrvmDwozUQcRUep7zM= X-Received: by 2002:a17:906:6847:: with SMTP id a7mr584646ejs.268.1625155067419; Thu, 01 Jul 2021 08:57:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yoann CONGAL Date: Thu, 1 Jul 2021 17:57:21 +0200 Message-ID: To: Ondrej Kozina Message-ID-Hash: 5KYVQW5XW5HB65N7LL4PTKIE76YV5L2X X-Message-ID-Hash: 5KYVQW5XW5HB65N7LL4PTKIE76YV5L2X X-MailFrom: yoann.congal@smile.fr X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dm-crypt.saout.de-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header CC: dm-crypt@saout.de X-Mailman-Version: 3.3.2 Precedence: list Subject: [dm-crypt] Re: LUKS container creation without device mapper or loop device access List-Id: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: multipart/mixed; boundary="===============6982116298448004152==" --===============6982116298448004152== Content-Type: multipart/alternative; boundary="0000000000007fae9d05c611e688" --0000000000007fae9d05c611e688 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Thanks a lot! My tests around your commands look really promising : This is exactly what I've looked for. Best Regards, Le mer. 30 juin 2021 =C3=A0 11:10, Ondrej Kozina a =C3= =A9crit : > Hi, > > On 6/18/21 10:22 AM, Yoann CONGAL wrote: > > > > From what I understood of the internals of cryptsetup, it knows how to > > build the LUKS header but rely on the dm-crypt module of the kernel to > > do the actual data encryption. (Please correct me if I'm wrong) > > Yes, dm-crypt is usually only necessary to access data when LUKS device > is activated (unlocked). That said, there are some exceptions. For > example when crypto backend used in libcryptsetup (or kernel crypto API) > does not support used cipher/mode for some reason. In that case we > fallback to use dm-crypt to perform encryption/decryption of LUKS > keyslots. It also requires root privs in this corner case. > > > > > So, I have two questions : > > * Do you know of a tool that does the full LUKS image (header and > > data) fully in userland? (I did search for it and found nothing) > > * If the above answer is "It does not exist yet", would you be open to > > its inclusion in cryptsetup? My guess is that a tightly managed intern > > may handle this. > With default cipher (aes) you can use new LUKS2 reencryption code for > that. LUKS2 header (cryptsetup format) can be created fully without need > to use dm-crypt already, but If you need to encrypt existing data you > can use following command: > > This should work without root privs. It will create separate detached > LUKS2 header in : > > cryptsetup reencrypt --encrypt --header > --disable-locks > > For header put in the beginning of the data file you can use: > > cryptsetup reencrypt --encrypt --reduce-device-size 32M > --disable-locks > > just bear in mind that my_data_file must have 32MiB spare space at the > end (iow there should be no useful data at the end of the file). > > With root privs, you can drop --disable-locks parameter and also use > block devices in place of . > > Look for more information related to online encryption under "reencrypt" > action of cryptsetup. > > Kind regards > Ondrej K. > > --=20 Yoann Congal Smile ECS - Expert technique yoann.congal@smile.fr --0000000000007fae9d05c611e688 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Thanks a lot! My tests a= round your commands look really promising : This is exactly what I've l= ooked for.

Best Regards,

Le=C2=A0mer. 30 ju= in 2021 =C3=A0=C2=A011:10, Ondrej Kozina <okozina@redhat.com> a =C3=A9crit=C2=A0:
Hi,

On 6/18/21 10:22 AM, Yoann CONGAL wrote:
>
>=C2=A0 From what I understood of the internals of cryptsetup, it knows = how to
> build the LUKS header but rely on the dm-crypt module of the kernel to=
> do the actual data encryption. (Please correct me if I'm wrong)
Yes, dm-crypt is usually only necessary to access data when LUKS device is activated (unlocked). That said, there are some exceptions. For
example when crypto backend used in libcryptsetup (or kernel crypto API) does not support used cipher/mode for some reason. In that case we
fallback to use dm-crypt to perform encryption/decryption of LUKS
keyslots. It also requires root privs in this corner case.

>
> So, I have two questions :
> * Do you know of a tool that does the full LUKS image (header and
> data) fully in userland? (I did search for it and found nothing)
> * If the above answer is "It does not exist yet", would you = be open to
> its inclusion in cryptsetup? My guess is that a tightly managed intern=
> may handle this.
With default cipher (aes) you can use new LUKS2 reencryption code for
that. LUKS2 header (cryptsetup format) can be created fully without need to use dm-crypt already, but If you need to encrypt existing data you
can use following command:

This should work without root privs. It will create separate detached
LUKS2 header in <new_detached_LUKS2_header>:

cryptsetup reencrypt --encrypt <my_data_file> --header
<new_detached_LUKS2_header> --disable-locks

For header put in the beginning of the data file you can use:

cryptsetup reencrypt --encrypt <my_data_file> --reduce-device-size 32= M
--disable-locks

just bear in mind that my_data_file must have 32MiB spare space at the
end (iow there should be no useful data at the end of the file).

With root privs, you can drop --disable-locks parameter and also use
block devices in place of <my_data_file>.

Look for more information related to online encryption under "reencryp= t"
action of cryptsetup.

Kind regards
Ondrej K.



--
Yoann Cong= al
Smile ECS - Expert technique<= /font>
--0000000000007fae9d05c611e688-- --===============6982116298448004152== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dm-crypt mailing list -- dm-crypt@saout.de To unsubscribe send an email to dm-crypt-leave@saout.de --===============6982116298448004152==--