I believe this is a known issue. I tried not encrypting /boot and the installer warned me that’s a security issue, so I don’t want to do that. FreeBSD’s boot loader doesn’t have this problem but I don’t think it’s possible to use that on Linux.
What can I do to avoid the long delay with Grub, but without compromising security?
I don’t consider having /boot unencrypted (vs full disk encryption) a security issue.
Some apparently do.
With /boot unencrypted, the single threaded and not optimized for this task grub doesn’t need to do the work of decrypting but the tools in the initramfs/initrd can do that.
You could use a different amount of iterations and perhaps a different cipher for your encryption - but I don’t know whether that is possible to change now, after the fact.
This is a fresh install, so I can keep trying until I get a suitable configuration. The main concern here is a root kit or other tampering with the kernel. It doesn’t have to be encrypted but I don’t know how I would detect tampering.
That’s a pretty serious threat model.
I don’t know whether systemd-boot or other boot loaders could be an alternative to grub to boot a fully encrypted system, whether it performs better.
but if the system except / isn’t encrypted
then it is as easy as inserting a bootable medium, boot it up and voila …
or just plain take the disk
and basically do whatever without any problem whatsoever
Use systemd boot and LUKS2 - add in the shim for secure boot - in firmware disable all boot options but your disk and lock your firmware.
Or just switch to systemd-boot (the installation by Calamares is GRUB and LUKS1).
It is technically possible to use a variation of secure boot on Arch based systems.
Nothing with GRUB then. It’s the key derivation algorithm of GRUB. When you create a LUKS device you use LUKS libraries that can profit of some hardware accerlerations. The key-derivation tries to hold a timelimit needed to crack your key on your machine or other machines with same power. GRUB’s LUKs function are’nt optimized versions and need much longer for the key-derivation function. If you want to use GRUB with faster unlocking then you have to go with lowering the cryptographical security. You can add with cryptsetup luksAddKey a new key with identical passphrase with as example --pbkdf-force-iterations=10000 parameter to reduce the iteration count of key-derivation function. Then delete with cryptsetup the old keyslot. Now, GRUB can unlock faster. But the security is reduced. To overcome it use a longer passphrase then.
And your passphrase should be stored into key slot 0, because GRUB tries each keyslot beginning with slot 0.
Unfortunately I have an old version of UEFI without secure boot, and no updates are available (Thinkpad W520). I would need some other way to verify the boot loader and kernel if those are not encrypted. An attacker could simply insert my drive into their own system to alter it.
You must live an exciting life on the edge - I mean I can understand encryption - but to be worried about disk replacement - that must be tough.
I live in fear of three-letter agencies.
some personal/universal “wisdom”:
fear is never a good advisor
awareness tends to be more productive
Good luck in your ways!