GRUB LUKS Slow boot

Would something like ...

cryptsetup-reencrypt --keep-key --hash sha256 /dev/"yourencryptedpartitionhere"

or

cryptsetup-reencrypt --keep-key --iter-time=5000 /dev/"yourencryptedpartitionhere"

be appropriate?

As other already stated - other distributions - may have altered the default installation to work around the issues where the encryption iterations are taking long time.

The harder the encryption - the harder the encryption is to be cracked - so what you deem non functional, a design error - to put it bluntly :slight_smile: - may just be a weaker encryption.


I can't say I have much experience in encrypted installation but it seems off to me that you need two passphrases.

The guides I have created on installing encrypted systems - is written during the installations - the latest was to learn btrfs and systemd-boot.

Those installs only asks for one passphrase - and you get to try three times in case you get it wrong - which also has been an issue for some which - using grub - only gets one shot.

Another point with relation to the guides - actually my notes during install - is that I followed the guide on Arch Wiki - using the same commands.


Therefore logic suggests you are using two different encryption containers - is it so and if so why?


I don't want to quarrel - that is not why I asked - I asked because I am curious and want to learn - know the thought(s) behind the statement.

You should get the proper context as stated on manjaro.org - scroll down the landing page (Emphasized by me).

Is an accessible, friendly, open-source Linux distribution and community. Based on Arch Linux, providing all the benefits of cutting-edge software combined with a focus on getting started quickly, automated tools to require less manual intervention, and help readily available when needed. Manjaro is suitable for both newcomers and experienced Linux users.

An excellent entry-point into the Linux world. Unlike proprietary operating systems, you have full control over your hardware, without restrictions. This makes it ideal for people who want to learn how Linux works and how it is different to other operating systems. From this perspective, it is also suitable for beginners similar to the way an Arduino is an excellent entry-point to embedded hardware development.

Manjaro is not a consumer-oriented operating system. You have full control and you will not be prevented from breaking your own installation - but then again, breaking things and fixing them is half of the fun! On the other hand, if you are happy with the way it works you don’t have to change a thing.

I also strongly believe it's the case in this scenario. But... Look at his screenshots - while it looks like he uses encryption for 2 different partitions, take a closer look at partition IDs - they are the same, except that one starts with luks-

This part is the most interesting to me...

I just reinstalled the system using auto-partitioning and now the system ask only one password (which is normal).

And now I'll try this:

It is along time ago that I did this. I checked the shell history and found this:

cryptsetup luksAddKey /dev/[luks_drive] -S 0 --pbkdf-force-iterations 300000

This is supposed to change the iterations for slot 0.

1 Like

Thanks!

@mbod, I've change the --iter-time for key slot 0 and removed the key slot 1. Reboot and the system is started to ask me for a password for the second time:

No key available with this passphrase.
Invalid keyfile. Reverting to passphrase.

I thought that adding key slot 1 with the same `--iter-time` system will stop asking me for the second time to decrypt the password, but I was wrong.
A password is required to access the luks-luks-f00dadec-cf3c-4f36-a645-cb0ef9e7ff16
Enter passphrase for /dev/nvme0n1p2:

EDIT.
Found this: Decryption problem

Why did you do that? I assume slot 1 contains a keyfile which is needed. Please check if you have a file /crypto_keyfile.bin. If yes, this should be added back to slot 1.

1 Like

Just an fyi ... the purpose of the high default cipher and iterations is to slow down the decryption process. This is useful in prevention of "fast" brute-force attacks.

Well, I guess I'll just press the "Solution" button.

Yeah, you can solve the situation, but not without dancing with a tambourine.
Thank you very much to everyone who answered on this subject. Special thanks to the user: @mbod. Thanks to his answers, I was able to find a solution (and understand the point):

  1. See this: [GRUB] [LUKS] Slow boot.
  2. And this: [GRUB] [LUKS] Slow boot.

I get the point of "problem". My opinion - users should have a choice of iteration value and a short explanation that the higher the number, the more protected they will be, but at the same time - the boot time will increase. IMO, the default value is too high.

1 Like

Just a quick question - if user decides to do so (which sounds like a perfect solution), will LUKS2 be used for encryption? Or will installer still use legacy LUKS1 (which only makes sense when using encrypted /boot because grub doesn't support LUKS2)?

You would have to ask the Calamares developers

I assume the latest iteration of LUKS will be used.

If you want to be sure - install by hand - it is not as hard as your may think.

Just consult the guides already linked in comment #13.

Grub has added support for LUKS2 a good month ago or so...

1 Like

That's great to hear, thanks for the update.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

Forum kindly sponsored by