Re: reencrypt: how to specify old and new key-files?
Philippe Cerfon <[email protected]>
| Newsgroups | dev.linux.lists.cryptsetup |
|---|---|
| Message-ID | <CAN+za=P-XaUsM2Xjy2Bip64PHKvYxCi8_d1wKiN_1o9AhEheLg@mail.gmail.com> |
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. 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.