You are not logged in.

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

belette
Member
Registered: 2014-11-17
Posts: 121

[SOLVED] accelerate cryptsetup decryption at boot

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)

Offline

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

ugjka
Member
From: Latvia
Registered: 2014-04-01
Posts: 1,658
Website

Re: [SOLVED] accelerate cryptsetup decryption at boot

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


Fix yo shit: journalctl -b -p warning
--- ugjka.net ---
"Learning the hard way is the only way for many."

Offline

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

belette
Member
Registered: 2014-11-17
Posts: 121

Re: [SOLVED] accelerate cryptsetup decryption at boot

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?

Offline

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

ugjka
Member
From: Latvia
Registered: 2014-04-01
Posts: 1,658
Website

Re: [SOLVED] accelerate cryptsetup decryption at boot

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)


Fix yo shit: journalctl -b -p warning
--- ugjka.net ---
"Learning the hard way is the only way for many."

Offline

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

belette
Member
Registered: 2014-11-17
Posts: 121

Re: [SOLVED] accelerate cryptsetup decryption at boot

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

Offline

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

ugjka
Member
From: Latvia
Registered: 2014-04-01
Posts: 1,658
Website

Re: [SOLVED] accelerate cryptsetup decryption at boot

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)


Fix yo shit: journalctl -b -p warning
--- ugjka.net ---
"Learning the hard way is the only way for many."

Offline

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

belette
Member
Registered: 2014-11-17
Posts: 121

Re: [SOLVED] accelerate cryptsetup decryption at boot

smile I was not as courageous as you smile
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 !

Offline

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

frostschutz
Member
Registered: 2013-11-15
Posts: 1,075

Re: [SOLVED] accelerate cryptsetup decryption at boot

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)

Offline

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

ugjka
Member
From: Latvia
Registered: 2014-04-01
Posts: 1,658
Website

Re: [SOLVED] accelerate cryptsetup decryption at boot

belette wrote:

smile I was not as courageous as you smile

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


Fix yo shit: journalctl -b -p warning
--- ugjka.net ---
"Learning the hard way is the only way for many."

Offline

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

belette
Member
Registered: 2014-11-17
Posts: 121

Re: [SOLVED] accelerate cryptsetup decryption at boot

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

Offline

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

digitalknight
Member
Registered: 2018-12-20
Posts: 1

Re: [SOLVED] accelerate cryptsetup decryption at boot

Is there a easy way to disable decryption all together?

Offline

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

Slithery
Forum Moderator
From: Norfolk, UK
Registered: 2013-12-01
Posts: 4,650

Re: [SOLVED] accelerate cryptsetup decryption at boot

Welcome to the forums digitalknight smile

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

Closing.


No, it didn't "fix" anything. It just shifted the brokeness one space to the right. - jasonwryan
Closing -- for deletion; Banning -- for muppetry. - jasonwryan

aur - dotfiles

Offline

Board footer

Powered by FluxBB