[Bug 1184069] New: GRUB on a crypted partition takes > 10 seconds to unlock the filesystem
http://bugzilla.opensuse.org/show_bug.cgi?id=1184069
Bug ID: 1184069 Summary: GRUB on a crypted partition takes > 10 seconds to unlock the filesystem Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Bootloader Assignee: screening-team-bugs@suse.de Reporter: p.heinlein@heinlein-support.de QA Contact: qa-bugs@suse.de Found By: --- Blocker: ---
I installed 15.2 plain vanilla on a Thinkpad X1.Extreme Gen.3 with a ~2 TB NVME and I set a crypto disc password during installation (in YaST).
Grub needs > 10 seconds to unlock the key, so booting is very slow.
It's very similar to
https://unix.stackexchange.com/questions/369414/grub-takes-too-long-to-unloc...
https://bbs.archlinux.org/viewtopic.php?id=228865
so I also think, that the crypto or number of iterations is way to expensive here and needs too much time. Maybe the SUSE team should/could look for a similar safe, but faster method (SHA256?) here?
http://bugzilla.opensuse.org/show_bug.cgi?id=1184069 http://bugzilla.opensuse.org/show_bug.cgi?id=1184069#c1
Andreas Stieger Andreas.Stieger@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Andreas.Stieger@gmx.de, | |p.heinlein@heinlein-support | |.de Flags| |needinfo?(p.heinlein@heinle | |in-support.de)
--- Comment #1 from Andreas Stieger Andreas.Stieger@gmx.de --- (In reply to Peer Heinlein from comment #0)
so I also think, that the crypto or number of iterations is way to expensive here and needs too much time. Maybe the SUSE team should/could look for a similar safe, but faster method (SHA256?) here?
What is the number of iterations configured (cryptsetup luksDump)? How many keyslots are active?
The number of iterations is determined during installation by cryptsetup and is calibrated to take about 1000ms. When the disk moves or the system configuration changes this no longer matches up.
On the running system when creating a volume, which value does luksFormat choose?
Maybe the SUSE team should/could look for a similar safe, but faster method (SHA256?) here?
For key derivation, fast hashes are insecure. You want slow hashes here.
http://bugzilla.opensuse.org/show_bug.cgi?id=1184069 http://bugzilla.opensuse.org/show_bug.cgi?id=1184069#c2
--- Comment #2 from Andreas Stieger Andreas.Stieger@gmx.de --- Correction: default time is 2 seconds...
$ cryptsetup --help [...] Default compiled-in key and passphrase parameters: Maximum keyfile size: 8192kB, Maximum interactive passphrase length 512 (characters) Default PBKDF for LUKS1: pbkdf2, iteration time: 2000 (ms) Default PBKDF for LUKS2: argon2i Iteration time: 2000, Memory required: 1048576kB, Parallel threads: 4
http://bugzilla.opensuse.org/show_bug.cgi?id=1184069 http://bugzilla.opensuse.org/show_bug.cgi?id=1184069#c3
--- Comment #3 from Peer Heinlein p.heinlein@heinlein-support.de --- It is a plain vanilla 15.2 installation on a new laptop. So just boot 15.2 installation and hit enter-enter-enter (but check the crypto-setup button). I haven't configured anything here and the disk never moved from somewhere.
linux:~ # cryptsetup luksDump /dev/nvme0n1p2 LUKS header information for /dev/nvme0n1p2
Version: 1 Cipher name: aes Cipher mode: xts-plain64 Hash spec: sha256 Payload offset: 4096 MK bits: 256 MK digest: be f0 1d e3 5f bf 43 e7 59 ba 56 bf d6 78 8f b3 ec ac a9 ce MK salt: d6 48 62 eb 30 98 bc e1 35 87 ea 01 4a 68 8e f7 d4 fb 8e 19 b6 12 e0 cf 3b a5 2c a4 50 e5 6c fc MK iterations: 251095 UUID: f9c3acad-947b-4469-9014-729f06305ee9
Key Slot 0: ENABLED Iterations: 4104014 Salt: cb 3e ab 86 93 e5 4d e7 f6 a3 cf aa 1f 59 60 a4 07 a8 01 86 c7 d5 2e 6b 0d ca bd 58 90 27 f3 84 Key material offset: 8 AF stripes: 4000 Key Slot 1: DISABLED Key Slot 2: DISABLED Key Slot 3: DISABLED Key Slot 4: DISABLED Key Slot 5: DISABLED Key Slot 6: DISABLED Key Slot 7: DISABLED
linux:~ # fdisk /dev/nvme0n1
Welcome to fdisk (util-linux 2.33.1). Changes will remain in memory only, until you decide to write them. Be careful before using the write command.
Command (m for help): p Disk /dev/nvme0n1: 1.9 TiB, 2048408248320 bytes, 4000797360 sectors Disk model: KXG6APNV2T04 TOSHIBA Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 7FD14B00-5765-44D4-9B70-48E7A4AA25FA
Device Start End Sectors Size Type /dev/nvme0n1p1 2048 1026047 1024000 500M EFI System /dev/nvme0n1p2 1026048 4000797326 3999771279 1.9T Linux LVM
Command (m for help): q
linux:~ #
http://bugzilla.opensuse.org/show_bug.cgi?id=1184069 http://bugzilla.opensuse.org/show_bug.cgi?id=1184069#c4
--- Comment #4 from Andreas Stieger Andreas.Stieger@gmx.de --- (In reply to Peer Heinlein from comment #3)
Iterations: 4104014
That seems excessive by about a factor of 4. Which kind of matches your 10s observation over the target 2s. Can you give the output of cryptsetup benchmark on this system, the PKDF2 lines?
http://bugzilla.opensuse.org/show_bug.cgi?id=1184069 http://bugzilla.opensuse.org/show_bug.cgi?id=1184069#c5
--- Comment #5 from Peer Heinlein p.heinlein@heinlein-support.de --- linux:~ # cryptsetup benchmark # Tests are approximate using memory only (no storage IO). PBKDF2-sha1 1696724 iterations per second for 256-bit key PBKDF2-sha256 1862479 iterations per second for 256-bit key PBKDF2-sha512 1546572 iterations per second for 256-bit key PBKDF2-ripemd160 1139756 iterations per second for 256-bit key PBKDF2-whirlpool 720175 iterations per second for 256-bit key # Algorithm | Key | Encryption | Decryption aes-cbc 128b 1109.4 MiB/s 3697.4 MiB/s serpent-cbc 128b 104.1 MiB/s 737.6 MiB/s twofish-cbc 128b 241.1 MiB/s 399.5 MiB/s aes-cbc 256b 965.6 MiB/s 3066.1 MiB/s serpent-cbc 256b 96.1 MiB/s 768.5 MiB/s twofish-cbc 256b 244.6 MiB/s 381.7 MiB/s aes-xts 256b 3592.9 MiB/s 3430.3 MiB/s serpent-xts 256b 737.0 MiB/s 632.3 MiB/s twofish-xts 256b 401.8 MiB/s 425.1 MiB/s aes-xts 512b 2830.5 MiB/s 2314.7 MiB/s serpent-xts 512b 670.7 MiB/s 736.8 MiB/s twofish-xts 512b 385.9 MiB/s 350.7 MiB/s
http://bugzilla.opensuse.org/show_bug.cgi?id=1184069 http://bugzilla.opensuse.org/show_bug.cgi?id=1184069#c6
Andreas Stieger Andreas.Stieger@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(p.heinlein@heinle | |in-support.de) |
--- Comment #6 from Andreas Stieger Andreas.Stieger@gmx.de --- Looks like you are experiencing exactly the problem you describe in your linked articles. The defaults offered by cryptsetup are too strong so that the slower grub implementation shows. The work-around is to weaken your defaults during the installation. I do not think that this should be weakened for all users through, since there are non-boot scenarios here.
http://bugzilla.opensuse.org/show_bug.cgi?id=1184069 http://bugzilla.opensuse.org/show_bug.cgi?id=1184069#c7
Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Ulrich.Windl@rz.uni-regensb | |urg.de
--- Comment #7 from Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de --- I don't know how the iterations count is determined, but it might be too high. Here I have 2286970 key slot iterations and 145635 MK iterations, resulting in more than 10 seconds. I'm aware that the paranoid might want a long time like 30 seconds to decrypt the key, but my guess is the average user is quite happy with 3 to 5 seconds. Maybe just make parameters configurable, or allow "expert setup" (manually creating the LUKS device).
http://bugzilla.opensuse.org/show_bug.cgi?id=1184069 http://bugzilla.opensuse.org/show_bug.cgi?id=1184069#c8
--- Comment #8 from Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de --- Maybe see also Bug 1185291.
http://bugzilla.opensuse.org/show_bug.cgi?id=1184069 http://bugzilla.opensuse.org/show_bug.cgi?id=1184069#c9
--- Comment #9 from Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de --- This question and the feature request for cryptsetup may also be interesting: https://superuser.com/questions/1645141/is-the-fastest-open-determined-by-pr... The recommendation is to convert to LUKSv2 to allow additional options like a preferred key slot.
http://bugzilla.opensuse.org/show_bug.cgi?id=1184069 http://bugzilla.opensuse.org/show_bug.cgi?id=1184069#c10
Andreas Stieger Andreas.Stieger@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |andihartmann@freenet.de
--- Comment #10 from Andreas Stieger Andreas.Stieger@gmx.de --- *** Bug 1200252 has been marked as a duplicate of this bug. ***
http://bugzilla.opensuse.org/show_bug.cgi?id=1184069 http://bugzilla.opensuse.org/show_bug.cgi?id=1184069#c11
--- Comment #11 from Klaus Mueller andihartmann@freenet.de --- I don't think a preferred key slot is the right way to go. It's rather a bad workaround - by far not the solution. Here it takes 22s to get the key on a Ryzen 7 1700X CPU. This is 21s more than it should take!
As there is a second key, you have to wait 44(!)s if I mistyped the passphrase. Afterwards you have to reboot, because grub even doesn't support to provide the passphrase (grub 2.06 / Leap 15.4) a second time ...
All together it seems to me that the partition / fs decryption is a very unloved child of the grub maintainers to put it diplomatically.
http://bugzilla.opensuse.org/show_bug.cgi?id=1184069 http://bugzilla.opensuse.org/show_bug.cgi?id=1184069#c12
--- Comment #12 from Andreas Stieger Andreas.Stieger@gmx.de --- (In reply to Klaus Mueller from comment #11)
Here it takes 22s to get the key on a Ryzen 7 1700X CPU. This is 21s more than it should take!
It is true that the key strengthening function is tuned to take about 1000ms for a single run to generate the key from the passphrase. The underlying problem is that the single-threaded performance for this operation has diverged so much from the running system to grub, so that strengthening parameters picked will make it run slower in grub. You can use different parameters, it is not fundamentally less secure.
http://bugzilla.opensuse.org/show_bug.cgi?id=1184069 http://bugzilla.opensuse.org/show_bug.cgi?id=1184069#c13
--- Comment #13 from Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de --- I think the main issue is that decrypting in GRUB takes significantly longer (factor 4, or so) than decrypting in the kernel. Maybe that issue should be addressed first.
http://bugzilla.opensuse.org/show_bug.cgi?id=1184069 http://bugzilla.opensuse.org/show_bug.cgi?id=1184069#c14
--- Comment #14 from Klaus Mueller andihartmann@freenet.de --- (In reply to Andreas Stieger from comment #12)
It is true that the key strengthening function is tuned to take about 1000ms for a single run to generate the key from the passphrase. The underlying problem is that the single-threaded performance for this operation has diverged so much from the running system to grub, so that strengthening parameters picked will make it run slower in grub.
This means: grub should urgently implement multi threaded operations to cope with the system capabilities. It's usual since years to parallelize work.
You can use different parameters, it is not fundamentally less secure.
The high number of iterations compensates for the poor entropy of probably most passphrases / passwords in the wild. That's how I understood it so far. Therefore it would be fatal to reduce the number of iterations to derive the key. If you have a big enough key initially derived from /dev/(u)random, it's surly possible to massively reduce the amount of iterations without reducing security at all most probably. Unfortunately, my passphrases don't reach this high entropy.
http://bugzilla.opensuse.org/show_bug.cgi?id=1184069
Andreas Stieger Andreas.Stieger@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|Bootloader |Bootloader Version|Leap 15.2 |Current Product|openSUSE Distribution |openSUSE Tumbleweed
http://bugzilla.opensuse.org/show_bug.cgi?id=1184069
Martin Jambor mjambor@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mjambor@suse.com
-
bugzilla_noreply＠suse.com