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?


1 Answer 1


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 --key-slot number.

The 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 --key-slot option:

cryptsetup -v luksOpen --test-passphrase --key-slot N <device>

Using the 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

From man cryptsetup:

  • --iter-time, -i

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

  • Only problem i now have is the message "No key with this passphrase. Passphrase required to access luks volume...." after creating a new slot, and deleting the old. There were two slots occupied, and I deleted both, and added only one new... could this be the problem? I am able to unlock by typing the password twice (once in grub, and another after grub...) Jan 31, 2019 at 21:00
  • That's worrying... if you use the --key-slot option for open then it only checks that slot, so maybe it's because "If the given passphrase would only match a different key-slot, the operation fails." But it does eventually unlock... I don't know why it's asking twice, unless that's just how manjaro is set up? I'm not sure, maybe it was storing the passphrase somewhere else on disk and now it's changed, or maybe there's two encrypted partitions? Keeping a header backup is in general always a good idea, or possibly even a --dump-master-key if you're worried about losing all passphrases
    – Xen2050
    Feb 1, 2019 at 10:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .