From: Ondrej Kozina <okozina@redhat.com>
To: cryptsetup@lists.linux.dev
Cc: Philippe Cerfon <philcerf@gmail.com>
Subject: Re: reencrypt: how to specify old and new key-files?
Date: Thu, 10 Nov 2022 10:24:13 +0100 [thread overview]
Message-ID: <37ecbf51-9c83-eb17-ef98-a68a9975ecd8@redhat.com> (raw)
In-Reply-To: <CAN+za=OaHi939USLRp8DttVjamBx7qSxOp-LPm6uNtMN7oek8A@mail.gmail.com>
Hi,
On 08. 11. 22 23:52, Philippe Cerfon wrote:
> Hey.
>
> Sorry for having to ask again.
>
> When I'm reencrypting a device in order to change the volume key and
> also the keyslot (say from PBKDF2 to Argon2) wouldn't there need to be
> some way to specify two different --key-file?
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.
>
> One for the old keyslot with the old VK, and one for the new keyslot
> to be generated?
>
> Especially if with --key-slot <old slot ID>, the old slot is
> overwritten and all others removed, as explained by the manpage:
>> For reencryption mode it selects specific keyslot (and passphrase)
>> that can be used to unlock new volume key. If used all other keyslots
>> get removed after reencryption operation is finished.
>
> But it seems there is only the --key-file option, for which it's even
> unclear to me, whether it's for the old or new keyslot/VK?
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.
The cryptsetup utility (reencrypt action) therefore supports only two
setups. Either you provide all passphrases for all currently active
keyslots (and all keyslots get recreated storing new/future volume key),
or you choose single keyslot and provide passphrase for it stored in
--key-file.
Again it's not big deal. You may change the old passphrase(s) before or
after reencryption operation completes.
We do plan to add support for initializing reencryption using different
unlock methods (e.g. LUKS2 tokens) but it will be added in future
version. For passphrase based activation the precondition for old and
new keyslot both having same passphrase will remain
O.
next prev parent reply other threads:[~2022-11-10 9:24 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 [this message]
2022-11-10 14:52 ` Philippe Cerfon
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=37ecbf51-9c83-eb17-ef98-a68a9975ecd8@redhat.com \
--to=okozina@redhat.com \
--cc=cryptsetup@lists.linux.dev \
--cc=philcerf@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox