Re: reencrypt: how to specify old and new key-files?

[Ondrej Kozina <okozina@redhat.com>]

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 <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.

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.
>