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 unlocking

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


  • 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 used

  • It also doesn't matter which filesystem is in use for the boot partition.

  • Just drop the iter count and use a good, strong password. Trying to brute force a 15 character password with only 52 unique characters in each position and requiring 1 second per guess is still going to take billions of years, and with twice the iter count you are only doubling that time. – psusi Jun 6 '17 at 0:52
  • @psusi But since my CPU is not very fast for key derivation, if I configure 1s of iter-time on it, it would require something like 1/4 of a second per guess (or less) for someone using a more modern desktop CPU. – Marc.2377 Jun 6 '17 at 17:33
  • And? 1/4 of many billions of years is still many billions of years.... – psusi Jun 7 '17 at 1:16
  • @psusi Oh, I didn't know how expensive SHA-512 actually is. I did some calculations and you... are right. The fastest I came up with was about 12 million years, on average (that is, to cover half of the search space), for a theoretical 1000 Amazon EC2 GPU instances. However, typing a 15-char random password, with uppercases, can take longer than the 10 seconds I'm experiencing and thus is too much of a hassle. I'm taking your advice, however, and lowering the iter-time. A 10-char password is more than enough at least in my case. – Marc.2377 Jun 7 '17 at 5:26
  • (Anyone reading my previous comment, please do note that a 10-char password is probably not safe for really secret (like enterprise-grade) data in the face of hardware-accelerated brute-force attacks. But this would go well beyond our scope here). – Marc.2377 Jun 7 '17 at 5:45

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?

| improve this answer | |
  • Thanks, I'm gonna try a different hashing. Regarding your last comment, I'm personally using encrypted /boot as an extra layer of protection from online tampering when dual-booting Windows (actually I don't dual-boot - yet, but I run it on a VM with direct disk access). Also there are a few solutions to detect and warn you if your (efi) bootloader has been tampered with. Like for instance mkinitcpio-chkcryptoboot. – Marc.2377 Jun 6 '17 at 17:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.