Very slow disk decryption at boot

LUKS decryption at startup of my freshly installed Manjaro XFCE 17.0 takes unusually long – at least 30 seconds.

I installed Manjaro XFCE 17.0 using the Calamares graphical installer on a Thinkpad T450s and opted for disk encryption with the default partition layout there. It seems the root partition and swap have been encrypted:

# lsblk
NAME                                     MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                                        8:0    0 238,5G  0 disk  
├─sda1                                     8:1    0   300M  0 part  /boot/efi
├─sda2                                     8:2    0 225,4G  0 part  
│ └─luks-335]                            254:0    0 225,4G  0 crypt /
└─sda3                                     8:3    0  12,8G  0 part  
  └─luks-c525[...]                       254:1    0  12,8G  0 crypt

I found this thread, but I believe I’m facing a different issue, because in my case no unnecessary 3rd slot is used:

# sudo cryptsetup luksDump /dev/sda2
LUKS header information for /dev/sda2

Version:       	1
Cipher name:   	aes
Cipher mode:   	xts-plain64
Hash spec:     	sha256
Payload offset:	4096
MK bits:       	512
MK digest:     	62 1c 49 aa 15 b9 66 43 d2 ac ad 60 9a 9e 81 89 f2 05 f1 a6 
MK salt:       	d3 df 90 73 31 dd 13 b9 7e 46 0d cd 69 cd df 5f 
           	    f3 e9 44 fb 06 70 d9 c9 0e f2 8f 93 08 aa b7 71 
MK iterations: 	144750
UUID:          	3356df35-8cf5-4b9f-bc2a-41dea0c52f03

Key Slot 0: ENABLED
    Iterations:         	1163634
    Salt:               	4c 45 bf 70 b1 fb 98 5b 31 ce 35 ae 14 85 b0 ff 
                      	    f6 ba bd 7b ac c3 ff c7 a7 ae 4d 4c 9d db 8f f2 
    Key material offset:	8
    AF stripes:            	4000
Key Slot 1: ENABLED
    Iterations:         	1150560
    Salt:               	2e 6d 4f 6a ab fc cb 4a 74 1f 9b 73 6a 62 69 fc 
                      	    c9 2b 92 15 75 09 d8 25 68 a9 9e db 6c dc e4 3f 
    Key material offset:	512
    AF stripes:            	4000
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

I guess I could replace (one of?) the keys with a new key with lower --iter-time, but, not fully understanding the security implications of the iter-time I choose, I’d like to know if there’s a better way to fix the issue.

Before switching to Manjaro, I usually followed tihs guide to ‘manually’ setup the encryption. On the same device, decryption went much faster then. However, I fail to see where the setup done by Calamares differs from my manual setup back then…

1 Like

Hey! So far - taken off from my threat that you linked - I got to the point where the key that actually unlocks the volume is the very first - and still it did not get a dime faster.

keys with a new key with lower --iter-time, but, not fully understanding the security implications of the iter-time I choose,

As far as I understand it that is the amount of iterations the actual decryption key is encrypted with the password you choose - so many many iterations slow down decryption - which also slows down bruteforceing it

Hm, that’s too bad to hear.

So no one knows what the real problem is here?

Btw. I think when I manually set it up on Arch, the partition was decrypted before grub. Is that possible? At least the prompt looked different, noticed immediately when I mis-typed, and let me try again rather than throwing me into rescue mode. Any idea what’s the difference in the setup compared to the guide I linked above?

Thanks

There are actually 2 grub loaders - one is on the non encrypted bit of the drive - that than decrypts the crypt volumes where another grub2 sits to then boot the OSes/kernels…

The version where you can retype is the one where /boot isn’t encrypted so an actual kernel can be loaded without runing any decryption first.

I’m facing the same problem. I just re-installed Manjaro 17.0 this week and decided to encrypt the hd this time.

My previous non-encyrpted Manjaro 17.0 booted in 9 seconds. But now after I enter my luks password at the grub screen, it takes 30-45 seconds before continuing on to boot on my i5-4300u cpu, 128 GB SSD, 8 GB Ram. So total boot time is about 60 seconds vs the previous 9 seconds for the unencrypted hd.

I also used the Calamares installer to setup the LUKS encryption. I don’t understand why 2 key slots are used, since I only chose 1 passphrase when setting up the encryption.

Hopefully, someone know how to fix this issue.

Thanks.

Check if aes_ni modules are loaded (only for CPUs that support these extensions).

I don’t have full disk encryption, but only a single LUKS data partition mounted under /data. There are no delays here. So probably only happens with full encryption.

It’s weird that you have 2 key slots, but I remember there was a topic here saying that LUKS (or Calamares) automatically added a second key. You should find that thread with the search function.

The process of unlocking the used Key is the “problem” - its by default so many thousand iterations that it takes a awful time - as soon as the keyslot is unlocked my system boots in 12s

1 Like

Yeah that could be the problem. I use a much lower iteration number and it’s unlocked almost immediately after entering the key.

1 Like

Thanks for the advice. I ended up temporarily adding a new LUKS Key to Slot 7, removing the Key in Slot 0, and then re-adding the key to Slot 0 using various --iter-time settings.

After experimentation, I settled on an iter-time setting of 500 vs the default of 2000. This reduced just the key unlocking time from about 30 seconds to 8 seconds on my machine, which seems more acceptable.

1 Like

8 seconds is still way too long.
I checked my iter-time setting, it’s set to something around 500000, and it’s unlocked in less than a second. But it’s just a data partition, mind. No / or /home.

Do you think there is a difference between the root partition and a normal data partition - other than the AES module is not loaded while booting?
I also don’t think the AES module is used for the key iteration itself - but I don’t know it for sure.

On my systems (SSD, i5, i7, r7) it takes about 5 seconds after entering the password before the boot process continues.

Bernhard

No I don’t think so. But what else could it be? I don’t think it’s normal to wait for more than 5 seconds for a partition to be decrypted. I may be wrong though.
Even on my old i7 without AES-NI it didn’t take more than 2 seconds.
Maybe it’s related to Calamares’ installation process? I set up my data partition outside of installers, just plain manual cryptsetup command in terminal.

Well, in general more iteration rounds provide a better protection against brute force attacks.
Maybe that is the reason the iteration count is higher on a new installation. I think I will have a look into the code because I also think that there could be the difference (Calamares generated disk encryption vs. manual installation of disk encryption).

Bernhard

is there a command to see how many itterations a keyslot has? - i did a default install with calamares so could provide that base data

My system is a T450s with an i7 (u version tough) and an SSD too. so actually plenty fast

sudo cryptsetup luksDump /dev/sdX

1 Like

muhaha Calamares opted for Iterations: 1383783
O.o quite a lot to do at the grub prompt.

There is one thing to note:
A Calamares installation has at least 2 encrypted partitions (root and swap).
I assume that it takes twice the time to open both that to open just one.

Also in https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions you can find the following section:

3.4 Unlocking a LUKS device takes very long. Why?

The iteration time for a key-slot (see Section 5 for an explanation
what iteration does) is calculated when setting a passphrase. By
default it is 1 second on the machine where the passphrase is set.
If you set a passphrase on a fast machine and then unlock it on a
slow machine, the unlocking time can be much longer. Also take into
account that up to 8 key-slots have to be tried in order to find the
right one.

I highlighted the relevant parts.
Now with 2 partitions and default settings (which are used by Calamares) one has to wait up to 16 seconds.
Please also note that there are 2 keys (Slot 0 and 1) installed into each partition. At the moment I don’t know why. But the key with my password is in slot 1 which means that I have to watch roughly 2+2 seconds for decryption.

Bernhard

Thanks for the explanation. I actually thought that Calamares created a LVM+LUKS setup, meaning only one crypto partition. Still think it’s slow :slight_smile:

2 keys are only installed if /boot is encrypted too, at least that’s my (very limited) understanding of the code:

if encrypt_hook:
        hooks.append("encrypt")
        if not unencrypted_separate_boot and \
           os.path.isfile(os.path.join(root_mount_point, "crypto_keyfile.bin")):
            files.append("/crypto_keyfile.bin")
if partition["mountPoint"] == "/boot" and "luksMapperName" not in partition:
            unencrypted_separate_boot = True

From https://github.com/manjaro/calamares/blob/development/src/modules/luksbootkeyfile/main.py

This module sets up a file crypto_keyfile.bin on the rootfs, assuming the rootfs
is LUKS encrypted and a passphrase is provided. This file is then included in the
initramfs and used for unlocking the rootfs from a previously unlocked GRUB2
session.

1 Like

No it does not - as at the grub stage only root is being encrypted - the swap is than later on during the kernel startup hooks unlocked with the help of a keyfile which is on the already unlocked root partition.

Oh @torvic has it already and even more detailed ^^

1 Like

Nice find.

Oh, You are right. There is an entry in /etc/crypttab for that. But then - how does the suspend mode work then (I don’t use it personally )?
I always thought the RAM is saved to the encrypted swap and then read from the unlocked swap partition. Or maybe this is done in initramfs… could work.

Forum kindly sponsored by Bytemark