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

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

[Philippe Cerfon]

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?

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?


Thanks,
Philippe

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

[Ondrej Kozina]

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.

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

[Philippe Cerfon]

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.

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.

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

[Ondrej Kozina]

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

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

[Philippe Cerfon]

Hey.

On Fri, Nov 11, 2022 at 11:39 AM Ondrej Kozina <okozina@redhat.com> wrote:
> Could you create an issue on
> https://gitlab.com/cryptsetup/cryptsetup please?

Done in https://gitlab.com/cryptsetup/cryptsetup/-/issues/785

Thanks,
Philippe.

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

[Philippe Cerfon]

One more thing which is a bit confusing to me:
- There's luksChangeKey (and the somewhat overlapping luksConvertKey)
which changes a keyslot key/passphrase and/or its KDF algo/params.
- cryptsetup reencrypt, also allows to change the KDF algo/params (but
not the keyslot key/passphrase), which makes that part of identical to
luksConvertKey.


With all of them (luksChangeKey, luksConvertKey, reencrypt), what does
cryptsetup do when I don't specify the --pbkdf / --iter-time /
--pbkdf-memory / --pbkdf-parallel / --pbkdf-force-iterations options?
- For reencrypt the manpage says that for --cipher, it would use the
existing algo when really re-encrypting and the default when freshly
encrypting.
- But what about these options, when I don't specify ANY of the KDF
algo/param options? Do they use the same than what's been there
before? Or the default?
- What, if one specifies ONLY SOME of them? E.g. it was previously
PBKDF2, and I do only --pbkdf argon2id  OR  only that and
--pbkdf-parallel 4 - will the others get defaults?

Tanks,
Philippe