On December 15, 2017 8:10:24 PM EST, Tobias Geerinckx-Rice <***@tobias.gr> wrote:
>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 <***@netris.org>
>>> ***@gnu.org (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.
>> 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, 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
>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
>optimised PBKDF2 implementations that can run in whatever CPU modes
>does, the only way to significantly reduce the wait is to use a
>‘--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.
>: This is from memory, but should be correct for all practical
>: I presume real-mode; don't ask me how UEFI affects all this.
Ah I definitely didn't think it through, using a key derivation function on the passphrase makes sense and definitely explains the slowness. Thanks for the explanation!