On December 15, 2017 8:10:24 PM EST, Tobias Geerinckx-Rice <[email protected]> wrote: >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 <[email protected]> >> wrote: >>> [email protected] (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.
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!
