I am using manjaro with full disk encrypt, however, the wait time at boot for decrypt is very long ( i assume because of a high difficulty setting) . How can I change encryption difficulty/ wait time of the encryption setup during install?
Too much passphrase hashing?
If it's only slow because you're waiting for a lot of passphrase hashing iterations, you could add a new passphrase with a quicker
--iter-time, but that could reduce security & allow faster guessing of passphrases. If you wanted to wait 1 second (1000ms) then use a command like:
cryptsetup -v luksAddKey --iter-time 1000 <device>
You might then have to delete the old slow passphrase (with
luksKillSlot), unless it's key slot is after the new quick one (they're apparently tested in order, so might have to wait for the first slow slot to be tested before the later quick one). Or change your initial open command to specify the new quicker
luksChangeKey command can combine the two steps, adding a new key then deleting the old key (even though the v1.7 man page doesn't specifically say it can use
--iter-time, apparently it can):
cryptsetup -v luksChangeKey --iter-time 1000 <device>
How slow is it now?
Test how long it takes to decrypt / open your device with:
cryptsetup -v luksOpen --test-passphrase <device>
Or test a specific key slot with the
cryptsetup -v luksOpen --test-passphrase --key-slot N <device>
time command might help, but also count your typing speed.
You can use the
luksDump command to see what the current key slot
Iterations: are, this is an example of a very slow slot 0 and a very quick slot 1:
Key Slot 0: ENABLED Iterations: 4663017 Salt: ...... Key material offset: 8 AF stripes: 4000 Key Slot 1: ENABLED Iterations: 1000 Salt: ...... Key material offset: 264 AF stripes: 4000
The number of milliseconds to spend with PBKDF2 passphrase processing. This option is only relevant for LUKS operations that set or change passphrases, such as luksFormat or luksAddKey. Specifying 0 as parameter selects the compiled-in default.
luksChangeKey <device> [<new key file>]
Changes an existing passphrase. The passphrase to be changed must be supplied interactively or via --key-file. The new passphrase can be supplied interactively or in a file given as positional argument.
If a key-slot is specified (via --key-slot), the passphrase for that key-slot must be given and the new passphrase will overwrite the specified key-slot. If no key- slot is specified and there is still a free key-slot, then the new passphrase will be put into a free key-slot before the key-slot containing the old passphrase is purged. If there is no free key-slot, then the key-slot with the old passphrase is overwritten directly.
WARNING: If a key-slot is overwritten, a media failure during this operation can cause the overwrite to fail after the old passphrase has been wiped and make the LUKS container inaccessible.
It's not the passphrase hashing?
- There's lots of reasons for a slow boot time, maybe it's unrelated to the encryption.
Or if the actual encryption/decryption itself is too slow, then changing the algorithm or key size might be required, and that would require decrypting and re-encrypting everything. There are programs (or commands in newer versions) that can do it in-place, hopefully without losing anything, but having a backup would be more than an excellent idea.
But in that case, it wouldn't just be a long initial wait but all reads & writes would be a little slower.
You can use the
cryptsetup -v benchmark command to see some speed tests, but "NOTE: This benchmark is using memory only and is only informative. You cannot
directly predict real storage encryption speed from it."