Arch Linux

belette

Member

Registered: 2014-11-17

Posts: 121

cryptsetup very slow to decrypt after another key added

Hi,

I am using cryptsetup for full disk encryption and everything is working well.
I have added another key with

cryptsetup luksAddKey /dev/partition

When I am using the first key my system needs around 5 seconds to decrypt and proceed to the boot.
When I am using the second key my system needs aroung 35 seconds!

Any idea what would be the issue?

Many thanks

belette

wudu

Member

Registered: 2010-03-08

Posts: 83

Re: cryptsetup very slow to decrypt after another key added

Hi,

depending on which slot you use it'll take more or less time, LUKS is testing the keys one by one till success. For me it's 2 seconds for the first key and 6 seconds for the second one but that is on a running system without load, not at boot.

frostschutz

Member

Registered: 2013-11-15

Posts: 1,421

Re: cryptsetup very slow to decrypt after another key added

Each key has its own iter count, by default cryptsetup tries to use about "1 second" of calculation time. This depends on the speed and current load of your machine as well as which crypt library cryptsetup is currently using for the hashing (gcrypt, kernel, openssl, nettle). When unlocking, as wudu said, each key is tried in turn so if you use 8 keys and want to unlock using the 8th key, it should take 8+ seconds to open. (Edit: I just tested it and it turns out it's actually 2+ seconds per key for me, so opening slot 012[3] takes 8+ seconds already)

If you move your install to a new machine with faster CPU it will take shorter; if you installed on a monster machine then move it to a slow nettop box, it will take ages to open. That's because cryptsetup does not dynamically adapt/update itercounts, it will stay the same until you change the key.

Have a look at your cryptsetup luksDump /dev/thing, it shows the itercounts. If you think they are too high you can change all keys, while using the --iter-time option to achieve a lower itercount to make unlocks faster.

You could also move keyslots around, so the key you use most often will be the first key it tries to open with.

Or you could just ignore the issue. The time it takes to open the crypt container is time well spent - the longer it takes, the harder it will be to bruteforce.

Last edited by frostschutz (2016-04-21 13:23:53)

jjacky

Member

Registered: 2011-11-09

Posts: 347

Website

Re: cryptsetup very slow to decrypt after another key added

In addition to what frostschutz said, if you know you're gonna use the key from a specific keyslot, you can use --key-slot to only use that keyslot, thus saving time to try all previous slots before getting there.

---

blog - github

belette

Member

Registered: 2014-11-17

Posts: 121

Re: cryptsetup very slow to decrypt after another key added

I forgot to say thanks all of you for your replies, receiving detailed replies like this remember me why I love to stay in Linux
I understand now the reason, it is due to the fact that my disk has multiple keys, one to decrypt /boot in grub and one to automatically decrypt the / (avoiding entering password twice)

I guess I have no way to use --key-slot in /etc/default/grub?
GRUB_CMDLINE_LINUX="cryptdevice=/dev/nvme0n1p2:nvme0n1p2_decrypted:allow-discards"

frostschutz

Member

Registered: 2013-11-15

Posts: 1,421

Re: cryptsetup very slow to decrypt after another key added

You'd probably have to edit the encrypt hook for that... by default, apart from allow-discards it will ignore all other options. Probably not worth it.

belette

Member

Registered: 2014-11-17

Posts: 121

Re: cryptsetup very slow to decrypt after another key added

Thanks! I guess it is not so easy to do... any idea where the file is and how complex it is?

frostschutz

Member

Registered: 2013-11-15

Posts: 1,421

Re: cryptsetup very slow to decrypt after another key added

lib/initcpio/hooks/encrypt

belette

Member

Registered: 2014-11-17

Posts: 121

Re: cryptsetup very slow to decrypt after another key added

thanks!
do you know if it is the same hooks used for Grub and for mkinitcpio?
I can see where I could potentially add the --key-slot parameters but I am not sure this would not affect mkinitcpio as well.
In fact my idea is to add --key-slot only for Grub decrypt process (this is where it is slow), for the second phase (auto decrypt thanks to a keyfile it is quick)