[SOLVED] accelerate cryptsetup decryption at boot

belette · 2017-01-06 19:30:53

Hi,

I am using a full disk encryption with /boot included (I don't have a separated /boot partition, everything is on / partition) thanks to Grub which has this option.
So basically when I boot up I have to enter my passphrase to decrypt the /boot and then Grub is starting the boot process.
Instead of having to enter 2 times my passphrase, I am using another key slot which is a file and I have added a FILES="mykeyfile.bin" into my mkinitcpio.conf.
Thanks to that I only need to enter my passphrase once.

My issue is that entering my passphrase it taking about 20 seconds to decrypt as it tries the slot in the order and if it fails it tries the next in the list.

I know there is a way to specify which key slot to use when using cryptsetup manually but how to specify it on grub ?

Many thanks!

Last edited by belette (2017-01-07 19:02:12)

ugjka · 2017-01-06 19:37:33

I have the same issue, it is pain in the ass but I guess that what you get when you want your boot encrypted

belette · 2017-01-06 22:19:48

don't you think there is a way to indicate to grub to use one specific key slot ? or pehaps hack the hook for mkinitcpio?

ugjka · 2017-01-06 22:30:51

Changing --iter-time value might help http://unix.stackexchange.com/questions … uks-device

https://bbs.archlinux.org/viewtopic.php?id=217193

I'll try cryptsetup-reencrypt with different --iter-time maybe tommorow

Last edited by ugjka (2017-01-06 23:05:36)

belette · 2017-01-07 10:28:28

many thanks for the links there are good references.
I am wondering if you have an idea of the last question of the guys in the second link :

Now this is solved, I am not sure which one is better -- whether keeping iter-time this low, or not encrypting the /boot partition at all and keeping the iter-time about 1 second for the encrypted root.

It is an important point to understand before playing with iter-time I guess..

ugjka · 2017-01-07 12:57:55

I changed --iter-time to 100 miliseconds for all my keyslots, and now boot is super duper fast. Sure now I'm now more prone to bruteforce attacks, but I'm fine with that

Last edited by ugjka (2017-01-07 12:59:09)

belette · 2017-01-07 19:01:51

I was not as courageous as you
I changed to 1000milliseconds and I already won half of the time I was used to wait... so with proper cipher and password > 50 characters long I think I am fine !

frostschutz · 2017-01-07 19:09:16

Lowering iter time may also lower your security. The iter time is what makes LUKS hard/impossible to bruteforce. Without itertime you have no such protection.

(You have to check itercounts for every LUKS container you create, sometimes the CPU is busy with other things resulting in an abysmally low itercount.)

If you can't tell grub to use a specific keyslot, you can still switch the keyslots themselves around so whatever passphrase you use for grub is also the first one in the LUKS header.

If you don't mind nixing security, you could also put your master key into the initramfs and thus circumvent LUKS altogether (use dmsetup create, instead of cryptsetup luksOpen, with what dmsetup table --showkeys shows). Of course anyone who gets their hands on that key can get at your data regardless how you change your passphrases in the future; you'd have to re-encrypt everything with a different masterkey.

Last edited by frostschutz (2017-01-07 19:10:01)

ugjka · 2017-01-07 19:17:08

belette wrote:

I was not as courageous as you

I'm not going to be the next Snowden, this is more a protection against thiefs and such.

belette · 2017-01-08 11:23:07

frostschutz wrote:

If you can't tell grub to use a specific keyslot, you can still switch the keyslots themselves around so whatever passphrase you use for grub is also the first one in the LUKS header.

I already tried to put the passphrase I write during grub decrypt process on the first slot but it didn't change anything and to be honest it doesn't make sense to me apart if grub has another mechanism which is different from cryptsetup

digitalknight · 2018-12-20 15:21:01

Is there a easy way to disable decryption all together?

Slithery · 2018-12-20 15:32:43

Welcome to the forums digitalknight

Please take the time to read the forum Code of Conduct before starting your own thread.

Closing.

Arch Linux

#1 2017-01-06 19:30:53

[SOLVED] accelerate cryptsetup decryption at boot

#2 2017-01-06 19:37:33

Re: [SOLVED] accelerate cryptsetup decryption at boot

#3 2017-01-06 22:19:48

Re: [SOLVED] accelerate cryptsetup decryption at boot

#4 2017-01-06 22:30:51

Re: [SOLVED] accelerate cryptsetup decryption at boot

#5 2017-01-07 10:28:28

Re: [SOLVED] accelerate cryptsetup decryption at boot

#6 2017-01-07 12:57:55

Re: [SOLVED] accelerate cryptsetup decryption at boot

#7 2017-01-07 19:01:51

Re: [SOLVED] accelerate cryptsetup decryption at boot

#8 2017-01-07 19:09:16

Re: [SOLVED] accelerate cryptsetup decryption at boot

#9 2017-01-07 19:17:08

Re: [SOLVED] accelerate cryptsetup decryption at boot

#10 2017-01-08 11:23:07

Re: [SOLVED] accelerate cryptsetup decryption at boot

#11 2018-12-20 15:21:01

Re: [SOLVED] accelerate cryptsetup decryption at boot

#12 2018-12-20 15:32:43

Re: [SOLVED] accelerate cryptsetup decryption at boot

Board footer