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.
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.