Security of Cryptsetup partition on Raspberry PI

Question

I cannot open one of my LUKS partitions on Raspberry PI due to the memory restriction. I already found out that the suggestion in this case is to recreate the partition on the slowest device, which will access it (in this case the Raspberry PI).

However, I'm concerned about the possibly decreased level of security (probably, with less computing power, a weaker key will be used).

This is what cryptsetup's documentation says about the issue:

Note: Passphrase iteration is determined by cryptsetup depending on CPU power. On a slow device, this may be lower than you want. I recently benchmarked this on a Raspberry Pi and it came out at about 1/15 of the iteration count for a typical PC. If security is paramount, you may want to increase the time spent in iteration, at the cost of a slower unlock later. For the Raspberry Pi, using

cryptsetup luksFormat -i 15000 <target device>

gives you an iteration count and security level equal to an average PC for passphrase iteration and master-key iteration. If in doubt, check the iteration counts with

cryptsetup luksDump <target device>

and adjust the iteration count accordingly by creating the container again with a different iteration time (the number after '-i' is the iteration time in milliseconds) until your requirements are met.

Now, I'm not sure what will happen, if I follow the advice above?

1. Will the partition be as secure as on a PC (if the iterations number is correct), just slower?
2. If it is slower, is only the unlock slower, or and later reads/writes are just as fast as without the extra iteration? (If so, why? Is it because by unlocking we only decrypt the key that will be later used to decrypt the content in the partition?)
3. Will it still consume less memory than the partition created on a fast PC? (In other words: I want to recreate the partition in order to be able to use it with Raspberry PI. With the default values it will be usable, but less secure. Will it still be usable with the increased iteration count, or would it again consume too much memory?)

Answer 1

First note that the LUKS documentation you were reading was written for LUKS1 and is somewhat out-of-date now. Everything you quoted (e.g. iteration count) is specific to the PBKDF2 algorithm, which your partition does not actually use.

LUKS2 supports two algorithms for converting your passphrase into a key: the traditional PBKDF2 as well as the newer Argon2. The latter is what LUKS now uses by default, and it's the only one which has an (adjustable) minimum required amount of memory needed. That isn't the same thing as "iteration count".

However, I'm concerned about the possibly decreased level of security (probably, with less computing power, a weaker key will be used).

You're not adjusting the key strength, you're adjusting the key's protection.

The parameters you're tweaking are meant to protect against someone trying to attack the pass­phrase you're entering – they prevent brute-force attacks (i.e. trying various passphrases in a row) by making the key derivation process impossibly slow.

However, the produced key is always equally strong on its own (it's as good as any other AES key), and nobody would bother attacking it directly.

If it is slower, is only the unlock slower, or and later reads/writes are just as fast as without the extra iteration? (If so, why? Is it because by unlocking we only decrypt the key that will be later used to decrypt the content in the partition?)

Every time you unlock the volume, LUKS converts your passphrase into an encryption key using a "key derivation function" (a KDF) so that the process will be more resistant to brute-force attacks – LUKS1 always used 'PBKDF2' which is resistant by means of being slow to compute (but doesn't impose any memory requirements), while LUKS2 additionally supports 'Argon2' which instead requires a certain amount of RAM.

The key derivation only happens once at unlock time; the rest (actual data encryption) does not need to involve passphrases at all.

(In other words: I want to recreate the partition in order to be able to use it with Raspberry PI. With the default values it will be usable, but less secure. Will it still be usable with the increased iteration count, or would it again consume too much memory?)

You don't need to recreate the partition at all, because even the passphrase-derived key is not used to encrypt your data directly: it only encrypts the master key stored in the LUKS volume header.

This is why it's possible to quickly change the passphrase without needing to reencrypt the whole disk (or even to have multiple passphrases), and likewise LUKS allows you to change the KDF parameters just as easily.

• If the default Argon2 parameters use too much memory, just tell that to LUKS:

  cryptsetup luksConvertKey --pbkdf "argon2i" --pbkdf-memory <num_kilobytes> <device>
  

• If you cannot use Argon2 at all, you can still tell LUKS to use PBKDF2 instead:

  cryptsetup luksConvertKey --pbkdf "pbkdf2" --iter-time <milliseconds> <device>
  

• Instead of milliseconds (which are device-dependent), you can directly specify the number of PBKDF2 iterations that you want (which always gives the same result no matter what device you do it on) – the default on a PC is somewhere around a million:

  cryptsetup luksConvertKey --pbkdf "pbkdf2" --pbkdf-force-iterations <count> <target>    
  

The same options are accepted by luksChangeKey (when changing the passphrase), in fact it seems they need to be specified every time you change the passphrase.