I have installed GRUB2 to an encrypted boot partition, as detailed here. The chosen hashing algorithm for my luksFormat is sha512, with the default iter-time (which is 2 seconds).This encrypted partition takes a little over 2 seconds to unlock if done from the command line (either from archiso or from the running system), but GRUB takes 10.5 seconds, on average, to unlock it. This is slower than acceptable for my scenario.I found other people having the same problem here and here. In the second link, user frostschutz has posted some hints about what might be causing this, of which I think 2 are very valid:1) The CPU might be running in power-saving mode during the early GRUB unlocking2) GRUB might be using a hashing implementation which is much slower than the system. He did a benchmark which can be found here.As encrypting the boot partition appears to be becoming more common, and there exists no satisfactory answer for this problem yet, I thought I'd ask about this. What can be done, apart from decreasing the iteration count (which substantially lowers security in an offline attack scenario), to counter this (much) slower decryption time by the GRUB bootloader?I'd like to at least pinpoint the exact cause. Is there a way to check (and maybe alter) the CPU clock in the bootloader screen? I know GRUB has a shell; I opened it and tried cat /proc/cpuinfo but it fails with /proc not found or something like that. I also tried cpuid, and whilst it doesn't fail, it also returns nothing.As additional information, I got these timings:GRUB takes 9 seconds or longer to unlock the boot partition (/boot) after typing the password and pressing Enter.The Kernel appears to take about 7 seconds to unlock the root partition (/). Again, this is timed after pressing Enter.The Kernel unlocks and mounts the boot partition (/boot) via crypttab in just over 2 seconds.Updates:I tried SHA256 hashing and it took longer (13 seconds). This probably indicates that GRUB must be using 64bits, as can be deduced from here, https://security.stackexchange.com/a/40218/91904 and in frostschutz's answer.Also tried SHA1 and it takes 11.5 seconds.It doesn't seem to make a difference whether AES256 or AES512 is usedIt also doesn't matter which filesystem is in use for the boot partition.
GRUB takes too long to unlock the encrypted boot partition
grub2;performance;encryption;boot loader
GRUB is early boot. There is no OS, no Linux available yet, although we tend to forget that since GRUB does so many amazing-crazy things all by itself. So a /proc not found message is not surprising. SHA512 benefits a lot from 64bit instructions but GRUB might not be able to use those yet. Try SHA256 or SHA1, maybe they work better for GRUB. It matters little which hash spec you use with LUKS as the iter counts will just be adapted accordingly. See How to change the hash-spec and iter-time of an existing dm-crypt LUKS device? on how to try that w/o re-encrypting everything.GRUB seems to be using some variant of gcrypt library for its hashing needs. I don't know if my very old benchmark is still valid. Back when I tested it was not the fastest library (at least the way it's used by cryptsetup benchmark) and there were surprisingly large differences.So if you are not using gcrypt with your cryptsetup binary that might be another reason for difference in time to unlock. Maybe you'll just have to experiment until you find a value that works for you.As encrypting the boot partition appears to be becoming more common,For all the wrong reasons... people tamper your /boot, people tamper your bootloader just as easily. GRUB only supports the most direct scheme, what's the point if it falls to a cheap keylogger?