For future reference:
Influence of cryptsetup’s iter-time, iterations and your CPU on GRUB2’s decryption time
‘=======================================================================’
LUKS uses PBKDF2 for key derivation. The supplied passphrase by the user is combined with a salt and hashed a specified number of rounds. This is called key stretching and makes the password more secure against brute force attacks. The total number of iterations is determined by the speed of the current hardware and can be influenced by setting the number of milliseconds that will be spent in PBKDF2 passphrase processing (–iter-time). At the time of writing the default iter-time is 2000 (2 seconds) for LUKS2. See here for other current defaults.
So, the unlock time for a key-slot is calculated for your specific hardware when setting a passphrase and defaults to 2 seconds. If you set a passphrase on a slow machine and then unlock it on a fast machine, the unlocking time can be much shorter and vice versa. Also take into account that up to 8 key-slots (LUKS2: up to 32 key-slots) have to be tried in order to find the right one.
A possible attacker will most certainly brute-force on high-end hardware, so you’ll benefit from a combination of a high iteration number and a secure password.
-
To check your current unlock time, run
TIMEFORMAT='%lU';time sudo cryptsetup luksOpen --test-passphrase --verbose <encrypted-device>
E. g. for the luks partition /dev/sda2, run
TIMEFORMAT='%lU';time sudo cryptsetup luksOpen --test-passphrase --verbose /dev/sda2
-
To check the current number of iterations of all your keyslots, run
sudo cryptsetup luksDump <encrypted-device> | grep -B1 "Iterations:"
-
To change the iteration number of a current passphrase, run
sudo cryptsetup luksChangeKey --pbkdf-force-iterations <iterations> <encrypted-device>
E. g. if your current iteration number is 2500000, use 5000000 as <iteration>-value to increase the iterations to the equivalent of 4 seconds (from 2s) unlock time for your specific hardware.
Why is the GRUB2 (boot) unlock time so much longer than the set iter-time?
GRUB is early bootstage. On a device with an encrypted /boot there is no OS (no Linux kernel) available yet. Unfortunately Grub’s implementation is really slow on most machines, since (unlike the kernel) it can only do pure software decryption or AES-NI, not SSE-accelerated decryption. Thus your first grub unlock stage will probably take multiple times longer than your set iter-time; multiple in this context meaning it could take 10 or more times longer than the calculated default 2 seconds. So the encryption will probably add about 20sec to the boot time for most users.
=> There is a linear relationship between your grub decryption time and your iteration count. You should be able to halve your grub unlock time by halving your keyslots iteration number.
So, why not simply decrease the iterations to reduce the grub unlock time?
You could, but this is generally a very bad idea, unless you only use high-entropy passphrases. If you decrease the iteration time without ensuring that, then you put your system at increased risk, and considering how rarely LUKS containers are unlocked in a typical work-flow, you do so without a good reason.
Don’t do it. The iteration time is already low enough that users with low entropy passphrases are vulnerable. Lowering it even further increases this danger significantly.
