All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philippe Cerfon <philcerf@gmail.com>
To: Ondrej Kozina <okozina@redhat.com>
Cc: cryptsetup@lists.linux.dev
Subject: Re: reencrypt: how to specify old and new key-files?
Date: Thu, 10 Nov 2022 15:52:28 +0100	[thread overview]
Message-ID: <CAN+za=P-XaUsM2Xjy2Bip64PHKvYxCi8_d1wKiN_1o9AhEheLg@mail.gmail.com> (raw)
In-Reply-To: <37ecbf51-9c83-eb17-ef98-a68a9975ecd8@redhat.com>

Hey Ondrej.

Thanks for your reply.

On Thu, Nov 10, 2022 at 10:24 AM Ondrej Kozina <okozina@redhat.com> wrote:
> It's not necessary. With LUKS2 you may change keyslot parameters without
> need for full device reencryption. You may split your goal into two
> individual steps. Reencrypt the device to refresh volume key and later
> change keyslot parameters as you see fit.

Wouldn't especially this order have some security downsides?

If one has e.g. a "weak" KDF (or weaker settings for it), or a weak
(e.g. one that
could have been leaked) passphrase then first re-encrypting the volume would
also re-encrypt the new VK, but with the old weak KDF and/or passphrase.

If one updates (I assume with luksChangeKey ?) the keyslot only afterwards,
the previously created new (intermediate) keyslot (with the new VK, but still
old KDF/passphrase) might have already been relocated to some other sector
on the HDD (or similar for SSD)?!


> It's for both, old and new keyslot. We do not want to support
> reencryption where old and new keyslot is unlocked by different
> passphrase for compatibility reasons. If LUKS2 reencryption gets
> interrupted (no matter the reason) it would be difficult to re-activate
> the device again unless it's fully reencrypted. Most libcryptsetup
> applications (including e.g. systemd) does not expect two different
> passphrase prompts while unlocking the device. So two passphrases prompt
> would break system boot, cryptsetup open scripts and so on.

Hmm I see, but at least from security point of view, I think - if my above
assumptions are correct - that this is rather unfortunate.

Cause even if we'd add some line describing the issue to the manpage or FAQ
it's all too likely that many people will never see it.

Still, when I'm right, such documentation should be added and emphasized.


> Either you provide all passphrases for all currently active
> keyslots (and all keyslots get recreated storing new/future volume key),

But as far as I understand, this mode wouldn't help with the above
problem, right?


Thanks,
Philippe.

  reply	other threads:[~2022-11-10 14:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-08 22:52 reencrypt: how to specify old and new key-files? Philippe Cerfon
2022-11-10  9:24 ` Ondrej Kozina
2022-11-10 14:52   ` Philippe Cerfon [this message]
2022-11-11 10:39     ` Ondrej Kozina
2022-11-11 13:22       ` Philippe Cerfon
2022-11-11 18:11       ` Philippe Cerfon

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='CAN+za=P-XaUsM2Xjy2Bip64PHKvYxCi8_d1wKiN_1o9AhEheLg@mail.gmail.com' \
    --to=philcerf@gmail.com \
    --cc=cryptsetup@lists.linux.dev \
    --cc=okozina@redhat.com \
    /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.