Hi Tobias, Tobias Geerinckx-Rice <[email protected]> skribis:
> 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. I see, thanks for the explanation! Apparently GRUB embeds a copy of libgcrypt, which is supposed to be somewhat optimized. Maybe there’s really nothing we can do. Ludo’.
