From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adam Van Ymeren Subject: Re: GRUB LUKS support is slow? Date: Fri, 15 Dec 2017 21:29:24 -0500 Message-ID: <4EA12739-475E-4C6C-BF1D-69EFE8CC2053@vany.ca> References: <87a7yjfy15.fsf@gnu.org> <87po7fzjqc.fsf@netris.org> <13AFAEE7-656C-4DC8-ACA5-A6F01DD89748@vany.ca> <323370e6-660e-0e7e-065b-39a7346c22cc@tobias.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:36787) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQ2EL-0003VL-3g for guix-devel@gnu.org; Fri, 15 Dec 2017 21:29:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eQ2EH-0000cw-3K for guix-devel@gnu.org; Fri, 15 Dec 2017 21:29:37 -0500 In-Reply-To: <323370e6-660e-0e7e-065b-39a7346c22cc@tobias.gr> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Tobias Geerinckx-Rice , guix-devel@gnu.org, mhw@netris.org, ludo@gnu.org On December 15, 2017 8:10:24 PM EST, Tobias Geerinckx-Rice = wrote: >Guix, > >I'm afraid you'll all be somewhat disappointed by the answer=2E=2E=2E > >Adam Van Ymeren wrote on 16/12/17 at 00:25: >> On December 15, 2017 5:53:15 PM EST, Mark H Weaver = =20 >> wrote: >>> ludo@gnu=2Eorg (Ludovic Court=C3=A8s) writes: >>>=20 >>>> I have an encrypted root=2E When GRUB asks me for my passphrase,=20 >>>> it takes 5=E2=80=9310 seconds after I hit enter before it displays th= e >>>> menu; then, once I've selected an entry, it takes another 5 seconds >>>> or so to boot=2E >>>>=20 >>>> It=E2=80=99s always been this way for me (that=E2=80=99s on UEFI), bu= t I=E2=80=99m >>>> sufficiently annoyed to write this message today=2E :-) >>>>=20 >>>> Are others experiencing this as well? Any hints? >>>=20 >>> I also use a LUKS-encrypted root partition, and the same thing=20 >>> happens to me=2E I would guess that the cryptographic operations in= =20 >>> GRUB are not well optimized, but I haven't looked closely=2E >>>=20 >>> Mark >>=20 >> Even unoptimized 5-10s seems pretty long=2E It's not like it has a >> lot of data to process=2E > >Alas, you'd be wrong :-) > >The whole point of the key derivation function (PBKDF2 in this case) is >to take a long time =E2=80=94 i=2Ee=2E, generate *a lot* of data =E2=80= =94 before deriving >the actual encryption key from your passphrase=2E It's basically a slow >hash, run many times over=2E That's the delay we're talking about here=2E > >PBKDF2 is designed to be =E2=80=98impossible=E2=80=99 to optimise, parall= elise, or cut >short[0], so there's no way around running several seconds of busy work >before you can even check a passphrase=2E > >On GuixSD, the default run time is: > > $ cryptsetup --help | grep iteration > -i, --iter-time=3Dmsecs 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=2E 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=2E > >Furthermore, as Ludo' discovered, it's very likely that both GRUB *and* >Linux will have to re-calculate the key, doubling the total time=2E > >> I have an encrypted root as well, I don't think it takes 5s after I=20 >> enter the passphrase to get the grub men, maybe 1 or 2=2E Next time I= =20 >> reboot I'll make a note of it=2E > >It takes about ~7s on my systems (rough guess; they're all servers >so I'm not that impatient)=2E It should *never* take less than 2 seconds >unless you or your distro changed =E2=80=98--iter-time=E2=80=99, or your = volumes were >encrypted on a different, slower machine, or something's just wrong=2E > > * * * > >TLDR: unfortunately, these delays sound quite normal=2E 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 >=E2=80=98--iter-time=E2=80=99 when creating volumes=2E > >It's probably not worth it=2E Your box will boot a few seconds faster; >your attacker just saw their brute-force speeds double =E2=80=94 or worse= =2E > >Kind regards, > >T G-R > >[0]: This is from memory, but should be correct for all practical > purposes=2E >[1]: I presume real-mode; don't ask me how UEFI affects all this=2E Ah I definitely didn't think it through, using a key derivation function o= n the passphrase makes sense and definitely explains the slowness=2E Thank= s for the explanation!