Make more sensible choice for LUKS full disk encryption parameters during install

Feedback Feature Request
1

Whenever I encrypt my disk using whatever installer of Manjaro opening the LUKS partition on boot takes very long. So I always need to change the iter time after install in order to not wait for about 10s for opening the LUKS partition (as described for example here: How to change luks encryption difficulty on manjaro full disk encrypt - Unix & Linux Stack Exchange).

I think Pop!_OS is doing a great job with the full disk encryption, so my suggestion is to either making the standard parameters more sensible or giving the user the choice to change them in the installer (at least in the architect).

Thanks a lot for your hard work on Manjaro.

1 Like
2

You mean these options for cryptsetup ... luksFormat ...
https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption#Encryption_options_for_LUKS_mode

You propose making the weaker encryption options the default in Calamares?
Well, Calamares is made not for Manjaro only, it’s a project of its own. Feature requests need to be discussed with its developers. Here is an example for such a request:

The user wants stronger encryption, you want weaker encryption. If I understand @adriaandegroot correctly Calamares uses the default values which are the weaker ones from the Arch Wiki page. So then you actually can’t improve them for your needs.

If I were you I would have partitioned manually with a separate unencrypted boot partition. This would boot much faster. You can still do it without reinstalling.

  • Do you have free unecrypted disk space?
  • If not, how big is your UEFI partition? Do you use for dual-boot with Windows?
1 Like
3

Issue is that grub does not utilize “those modern cpu instructions that speed up hashing and crypto”.

When calamares is generating keys with --iter-time 2000 (2 seconds) the crypto lib makes full use of all those special cpu instructions.

Now when grub does it, it is like 5 times slower because the lib it uses is not able to utilize those cpu instructions. Now you wait 10 sec. instead of 2…

Also since /boot and root fs is encrypted it needs to unlock twice…

1 Like
4

So, a sensible request with highest utility would be to ask Adriaan to make a radio button appear if the user checks the “encrypt” checkbox

  • make /boot encrypted - more secure, but slow to start up (approx. 10 sec)
  • leave /boot unencrypted - less secure, but faster to start up (approx. 2 sec)
2 Likes
5

Are they using full disk encryption though? If they do, do they have some secret patch to grub or are they using less secure encryption by default? Do you get graphical password dialog for decryption or just a black screen?

If you still have such pop!_os installation, would you mind posting the output of lsblk? I would be very interested in in implementing their solution if it solves the slow fde boot in a reasonable manner.

1 Like
6

Just happen to come across this thread and have a pop_os install available. The typical ububu install has a graphical password dialog, but isn’t really “full disk” encryption, just the root fs and cryptswap. Pop_os itself also no longer uses grub and instead uses the systemd-bootloader with kernelstub configuration tool. It is a great user experience to be fair.

$ lsblk 
NAME            MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
nvme0n1         259:0    0 476.9G  0 disk  
├─nvme0n1p1     259:1    0   498M  0 part  /boot/efi
├─nvme0n1p2     259:2    0     4G  0 part  /recovery
├─nvme0n1p3     259:3    0 468.4G  0 part  
│ └─cryptdata   253:0    0 468.4G  0 crypt 
│   └─data-root 253:1    0 468.4G  0 lvm   /
└─nvme0n1p4     259:4    0     4G  0 part  
  └─cryptswap   253:2    0     4G  0 crypt [SWAP]