Re: reencrypt: how to specify old and new key-files?
Ondrej Kozina <[email protected]>
| Newsgroups | dev.linux.lists.cryptsetup |
|---|---|
| Message-ID | <[email protected]> |
On 10. 11. 22 15:52, Philippe Cerfon wrote: > Hey Ondrej. > > Thanks for your reply. > > On Thu, Nov 10, 2022 at 10:24 AM Ondrej Kozina <[email protected]> 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. Sorry, I did not mean in that particular order. I've forgotten the golden rule of re-read the post first before you hit send. The idea I was emphasizing is that changing keyslot parameters and volume key refresh (aka reencryption) are two independent tasks. > > 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. Yup, we should mention it somewhere. Also we may add an example in cryptsetup-reencrypt man page. Could you create an issue on https://gitlab.com/cryptsetup/cryptsetup please? Thanks O. > 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. >