Re: GRUB LUKS support is slow?

[Tobias Geerinckx-Rice]

Guix,

I'm afraid you'll all be somewhat disappointed by the answer...

Adam Van Ymeren wrote on 16/12/17 at 00:25:
> On December 15, 2017 5:53:15 PM EST, Mark H Weaver <address@hidden> 
> wrote:
>> address@hidden (Ludovic Courtès) writes:
>> 
>>> I have an encrypted root.  When GRUB asks me for my passphrase, 
>>> it takes 5–10 seconds after I hit enter before it displays the
>>> menu; then, once I've selected an entry, it takes another 5 seconds
>>> or so to boot.
>>> 
>>> It’s always been this way for me (that’s on UEFI), but I’m
>>> sufficiently annoyed to write this message today.  :-)
>>> 
>>> Are others experiencing this as well?  Any hints?
>> 
>> I also use a LUKS-encrypted root partition, and the same thing 
>> happens to me.  I would guess that the cryptographic operations in 
>> GRUB are not well optimized, but I haven't looked closely.
>> 
>> Mark
> 
> Even unoptimized 5-10s seems pretty long.  It's not like it has a
> lot of data to process.

Alas, you'd be wrong :-)

The whole point of the key derivation function (PBKDF2 in this case) is
to take a long time — i.e., generate *a lot* of data — before deriving
the actual encryption key from your passphrase. It's basically a slow
hash, run many times over. That's the delay we're talking about here.

PBKDF2 is designed to be ‘impossible’ to optimise, parallelise, or cut
short[0], so there's no way around running several seconds of busy work
before you can even check a passphrase.

On GuixSD, the default run time is:

  $ cryptsetup --help | grep iteration
  -i, --iter-time=msecs        PBKDF2 iteration time for LUKS (in ms)
  Default PBKDF2 iteration time for LUKS: 2000 (ms)

However, this run time is measured at volume creation time, with all
fancy CPU features available. It wouldn't surprise me if real-mode[1]
GRUB and the early kernel code are badly optimised and take longer to
complete the same number of iterations to obtain the key.

Furthermore, as Ludo' discovered, it's very likely that both GRUB *and*
Linux will have to re-calculate the key, doubling the total time.

> I have an encrypted root as well, I don't think it takes 5s after I 
> enter the passphrase to get the grub men, maybe 1 or 2.  Next time I 
> reboot I'll make a note of it.

It takes about ~7s on my systems (rough guess; they're all servers
so I'm not that impatient). It should *never* take less than 2 seconds
unless you or your distro changed ‘--iter-time’, or your volumes were
encrypted on a different, slower machine, or something's just wrong.

                                * * *

TLDR: unfortunately, these delays sound quite normal. Aside from writing
optimised PBKDF2 implementations that can run in whatever CPU modes GRUB
does[1], the only way to significantly reduce the wait is to use a lower
‘--iter-time’ when creating volumes.

It's probably not worth it. Your box will boot a few seconds faster;
your attacker just saw their brute-force speeds double — or worse.

Kind regards,

T G-R

[0]: This is from memory, but should be correct for all practical
     purposes.
[1]: I presume real-mode; don't ask me how UEFI affects all this.