Arch Linux

kolana

Member

Registered: 2021-02-12

Posts: 76

luks reduce number of iteration for faster system startup

I have encrypted luks partition of 100GB that contains my arch os

the problem that it takes too much time after i enter luks password in system startup

╰─ sudo cryptsetup luksDump /dev/xxx
LUKS header information
Version:       	2
Epoch:         	4
Metadata area: 	16384 [bytes]
Keyslots area: 	16744448 [bytes]
UUID:          	xxxxxxxx
Label:         	(no label)
Subsystem:     	(no subsystem)
Flags:       	(no flags)

Data segments:
  0: crypt
	offset: 16777216 [bytes]
	length: (whole device)
	cipher: aes-xts-plain64
	sector: 512 [bytes]

Keyslots:
  0: luks2
	Key:        512 bits
	Priority:   normal
	Cipher:     aes-xts-plain64
	Cipher key: 512 bits
	PBKDF:      argon2i
	Time cost:  4
	Memory:     871096
	Threads:    4
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
	AF stripes: 4000
	AF hash:    sha256
	Area offset:32768 [bytes]
	Area length:258048 [bytes]
	Digest ID:  0
Tokens:
Digests:
  0: pbkdf2
	Hash:       sha256
	Iterations: 89407

i saw a tip here that suggests to make it 1000 iteration.
https://wiki.archlinux.org/title/GRUB/T … on_in_GRUB

i have very very long secure password for luks.

should i downgrade to 1000?
is that command safe to execute?
should i run that command in terminal why my os is running then reboot the system and all will go smooth?

Last edited by kolana (2023-08-05 23:33:21)

twelveeighty

Member

Registered: 2011-09-04

Posts: 1,453

Re: luks reduce number of iteration for faster system startup

How long is "too much time" for you? Typically, LUKS takes only a second or so to unlock, what are you experiencing?

mpan

Member

Registered: 2012-08-01

Posts: 1,615

Website

Re: luks reduce number of iteration for faster system startup

Passphrase length and partition size do not play a role here. Only parameters of the key derivation function.

RFC 9106 suggests time factor of 3 for Argon2i. So you may try decreasing it from 4 to 3.

As for security: the lower cost parameters, the easier the attack is for the adversary. There is no universal “good enough” either. As noted by twelveeighty, the question remains: how much is “too much”? I use Intel E5300, which is a 2008 CPU. The benchmark requires merely 2 seconds to finish (4 iterations, 275941 memory, 4 parallel threads).

---

Paperclips in avatars?

kolana

Member

Registered: 2021-02-12

Posts: 76

Re: luks reduce number of iteration for faster system startup

How long is "too much time" for you? Typically, LUKS takes only a second or so to unlock, what are you experiencing?

from when clicking ENTER after typing luks password to see gnome login prompt appears it takes 1 minute and 16 seconds.
from when clicking ENTER after typing luks password to the end of cursor blinking (then i start see system bootup log on screen -> i suppose that decryption ends here) it takes 20 seconds.

--> 20 seconds luks decryption.

My Drive is HDD.

Last edited by kolana (2023-08-06 10:04:16)

kolana

Member

Registered: 2021-02-12

Posts: 76

Re: luks reduce number of iteration for faster system startup

Passphrase length and partition size do not play a role here. Only parameters of the key derivation function.

RFC 9106 suggests time factor of 3 for Argon2i. So you may try decreasing it from 4 to 3.

As for security: the lower cost parameters, the easier the attack is for the adversary. There is no universal “good enough” either. As noted by twelveeighty, the question remains: how much is “too much”? I use Intel E5300, which is a 2008 CPU. The benchmark requires merely 2 seconds to finish (4 iterations, 275941 memory, 4 parallel threads).

from when clicking ENTER after typing luks password to see gnome login prompt appears it takes 1 minute and 16 seconds.
from when clicking ENTER after typing luks password to the end of cursor blinking (then i start see system bootup log on screen -> i suppose that decryption ends here) it takes 20 seconds.

--> 20 seconds luks decryption.

My Drive is HDD.

twelveeighty

Member

Registered: 2011-09-04

Posts: 1,453

Re: luks reduce number of iteration for faster system startup

20 seconds luks decryption.

Examine and/or post (via 0x0 or ix) your journal from the last boot.

kolana

Member

Registered: 2021-02-12

Posts: 76

Re: luks reduce number of iteration for faster system startup

20 seconds luks decryption.

Examine and/or post (via 0x0 or ix) your journal from the last boot.

what exact command you want its output ?

kolana

Member

Registered: 2021-02-12

Posts: 76

Re: luks reduce number of iteration for faster system startup

20 seconds luks decryption.

Examine and/or post (via 0x0 or ix) your journal from the last boot.

sudo journalctl -b -> https://0x0.st/H_Ke.txt

twelveeighty

Member

Registered: 2011-09-04

Posts: 1,453

Re: luks reduce number of iteration for faster system startup

sudo journalctl -b

kolana

Member

Registered: 2021-02-12

Posts: 76

Re: luks reduce number of iteration for faster system startup

sudo journalctl -b

https://0x0.st/H_Ke.txt

mpan

Member

Registered: 2012-08-01

Posts: 1,615

Website

Re: luks reduce number of iteration for faster system startup

In the linked log the crypto-related parts are short and end almost soon after the boot. A lot of time is dedicated to seemingly unrelated units. With a lot of warnings/errors.

Please post the full output of both of these commands:⁽¹⁾

systemd-analyze critical-chain
systemd-analyze blame

You may also wish to run this command to get a nice visual representation for your own purposes (no need for posting it here):

systemd-analyze plot > plot.svg

The SVG file should be openable in any modern graphical webbrowser.

While censoring information, please balance your privacy and our ability to help. In the first post you removed device UUIDs, making it impossible for us to make links between different logs.
____
⁽¹⁾ systemd-analyze manual

Last edited by mpan (2023-08-06 20:51:39)

---

Paperclips in avatars?

kolana

Member

Registered: 2021-02-12

Posts: 76

Re: luks reduce number of iteration for faster system startup

In the linked log the crypto-related parts are short and end almost soon after the boot. A lot of time is dedicated to seemingly unrelated units. With a lot of warnings/errors.

Please post the full output of both of these commands:⁽¹⁾

systemd-analyze critical-chain
systemd-analyze blame

You may also wish to run this command to get a nice visual representation for your own purposes (no need for posting it here):

systemd-analyze plot > plot.svg

The SVG file should be openable in any modern graphical webbrowser.

While censoring information, please balance your privacy and our ability to help. In the first post you removed device UUIDs, making it impossible for us to make links between different logs.
____
⁽¹⁾ systemd-analyze manual

Here are the needed files. sorry for earlier inconvenience

systemd-analyze critical chain

The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

graphical.target @1min 12.850s
└─multi-user.target @1min 12.850s
  └─plymouth-quit-wait.service @32.663s +40.186s
    └─systemd-user-sessions.service @32.583s +55ms
      └─nss-user-lookup.target @43.267s

systemd-analyze blame -> https://0x0.st/H_Tu.txt

systemd-analyze plot -> https://cdn-145.letsupload.cc/0b5cZ76cz … 5/plot.svg

mpan

Member

Registered: 2012-08-01

Posts: 1,615

Website

Re: luks reduce number of iteration for faster system startup

Indeed seems a bit high.

If you truly want to shave off a few seconds from a process taking 1.5 minutes, you may try decreasing the time factor from 4 to 3. Maybe, at the high load during a boot process, the KDF indeed gets slow. But you got a fair warning regarding both making an attack a bit cheaper to the adversary and that you are saving a few percent of the boot time.

Alternatively you may try reducing (for example halving?) the memory factor. Argon2 is designed to depend heavily on RAM. While the amount of memory used is negligible for modern systems,⁽¹⁾ this factor also increases amount of data transferred between RAM and CPU. And this is another very scarce resource during a boot.

Other than that I have no ideas.
____
⁽¹⁾ In the PC, laptop and server segments.

Last edited by mpan (2023-08-07 14:10:54)

---

Paperclips in avatars?

kolana

Member

Registered: 2021-02-12

Posts: 76

Re: luks reduce number of iteration for faster system startup

Indeed seems a bit high.

If you truly want to shave off a few seconds from a process taking 1.5 minutes, you may try decreasing the time factor from 4 to 3. Maybe, at the high load during a boot process, the KDF indeed gets slow. But you got a fair warning regarding both making an attack a bit cheaper to the adversary and that you are saving a few percent of the boot time.

Alternatively you may try reducing (for example halving?) the memory factor. Argon2 is designed to depend heavily on RAM. While the amount of memory used is negligible for modern systems,⁽¹⁾ this factor also increases amount of data transferred between RAM and CPU. And this is another very scarce resource during a boot.

Other than that I have no ideas.
____
⁽¹⁾ In the PC, laptop and server segments.

Ok,

so, cryptsetup luksChangeKey --pbkdf-force-iterations 3000 /dev/sdaX ?

is that command safe to execute?
should i run that command in terminal while my os is running then reboot the system and all will go smooth?

otherwise, for the 2nd point how to decrease memory factor, wym ?

mpan

Member

Registered: 2012-08-01

Posts: 1,615

Website

Re: luks reduce number of iteration for faster system startup

See the earlier post and also the manual for cryptsetup luksChangeKey.

---

Paperclips in avatars?

kolana

Member

Registered: 2021-02-12

Posts: 76

Re: luks reduce number of iteration for faster system startup

See the earlier post and also the manual for cryptsetup luksChangeKey.

i mean running cryptsetup luksChangeKey --pbkdf-force-iterations 3000 /dev/sdaX then restarting arch won't break my system ?

mpan

Member

Registered: 2012-08-01

Posts: 1,615

Website

Re: luks reduce number of iteration for faster system startup

My honest recommendation? Do not change anything and leave it as it is.

The way you ask this question, in particular repeating it, indicates you don’t understand command’s meaning and just blindly copy-paste it from the wiki. And it seems you don’t want to put an effort into understanding either the command or the cryptographic concepts behind it. Which is a prerequisite to do this safely and in a conscious manner. At this point it’s very likely you will only hurt yourself and lose your data.

Answering the question directly: it will not literally break your system. But it will make it unusable for practical purposes, including the possibility of not being able to access your data in any reasonable time and financial cost.

Last edited by mpan (2023-08-08 14:34:31)

---

Paperclips in avatars?