All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael Kjörling" <michael@kjorling.se>
To: cryptsetup@lists.linux.dev
Subject: Re: [Question] Distinction responsibilities LUKS and dm-crypt
Date: Fri, 1 Apr 2022 08:45:41 +0000	[thread overview]
Message-ID: <04746dcc-945a-400a-bad7-747bf881bd69@localhost> (raw)
In-Reply-To: <8583a15d8b2a72eebb72950a3cbf210bc74649d1.camel@scientia.org>

On 31 Mar 2022 21:32 +0200, from calestyo@scientia.org (Christoph Anton Mitterer):
> Some people may say that with "plain" /.../
> /.../
> It may have some tiny advantages when using it for temporary devices
> (like temporarily encrypted swap devices).

For that use case I would prefer to say that using LUKS has no added
benefit over a plain dm-crypt mapping, because the key material would
be thrown away on a reboot anyway. (Effectively giving swap the same
largely-emphemeral storage properties as RAM.) You _can_ do the same
thing by reformatting a LUKS container before passing it to swapon(8),
but doing so has no significant benefit that I can see compared to
just re-opening a plain dm-crypt mapping with a key read each time
from /dev/{u,}random and treating any pre-existing data as garbage.

Another use case for plain dm-crypt mappings is when you want to
pre-fill a storage device with random data to conceal which parts are
in use by what's inside a LUKS container: my experience is that it's
much faster to open a dm-crypt mapping with a throwaway key and then
write from /dev/zero through it, than is writing from /dev/{u,}random
to the raw backing device, and absent the key the output of any
competent encryption algorithm _should_ be indistinguishable from
random anyway. But maybe with the up-and-coming changes to
/dev/{u,}random in Linux that'll be subject to change.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
 “Remember when, on the Internet, nobody cared that you were a dog?”


  reply	other threads:[~2022-04-01  8:45 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-31 18:21 [Question] Distinction responsibilities LUKS and dm-crypt Surmont Jasper
2022-03-31 18:29 ` Christoph Anton Mitterer
     [not found]   ` <PR3P192MB10874E4159B71C71097583B4F1E19@PR3P192MB1087.EURP192.PROD.OUTLOOK.COM>
2022-03-31 19:32     ` Christoph Anton Mitterer
2022-04-01  8:45       ` Michael Kjörling [this message]
2022-03-31 18:52 ` Arno Wagner
2022-03-31 18:58 ` Michael Kjörling

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=04746dcc-945a-400a-bad7-747bf881bd69@localhost \
    --to=michael@kjorling.se \
    --cc=cryptsetup@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.