From: Tobias Geerinckx-Rice <me@tobias.gr>
To: adam@vany.ca, guix-devel@gnu.org, mhw@netris.org, ludo@gnu.org
Subject: Re: GRUB LUKS support is slow?
Date: Sat, 16 Dec 2017 02:10:24 +0100 [thread overview]
Message-ID: <323370e6-660e-0e7e-065b-39a7346c22cc@tobias.gr> (raw)
In-Reply-To: <13AFAEE7-656C-4DC8-ACA5-A6F01DD89748@vany.ca>
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 <mhw@netris.org>
> wrote:
>> ludo@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.
>>
>> 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.
next prev parent reply other threads:[~2017-12-16 1:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-15 22:04 GRUB LUKS support is slow? Ludovic Courtès
2017-12-15 22:53 ` Mark H Weaver
2017-12-15 23:25 ` Adam Van Ymeren
2017-12-16 1:10 ` Tobias Geerinckx-Rice [this message]
2017-12-16 2:29 ` Adam Van Ymeren
2017-12-18 9:38 ` Ludovic Courtès
2017-12-18 9:39 ` Ludovic Courtès
2017-12-18 21:28 ` Tobias Geerinckx-Rice
2017-12-16 1:14 ` Clément Lassieur
2017-12-16 8:10 ` Chris Marusich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=323370e6-660e-0e7e-065b-39a7346c22cc@tobias.gr \
--to=me@tobias.gr \
--cc=adam@vany.ca \
--cc=guix-devel@gnu.org \
--cc=ludo@gnu.org \
--cc=mhw@netris.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.