http://bugzilla.opensuse.org/show_bug.cgi?id=1184069 http://bugzilla.opensuse.org/show_bug.cgi?id=1184069#c1 Andreas Stieger 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 --- (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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1184069 http://bugzilla.opensuse.org/show_bug.cgi?id=1184069#c3 --- Comment #3 from Peer Heinlein --- 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:~ # -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1184069 http://bugzilla.opensuse.org/show_bug.cgi?id=1184069#c5 --- Comment #5 from Peer Heinlein --- 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 -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1184069 http://bugzilla.opensuse.org/show_bug.cgi?id=1184069#c7 Ulrich Windl changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Ulrich.Windl@rz.uni-regensb | |urg.de --- Comment #7 from Ulrich Windl --- 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). -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1184069 http://bugzilla.opensuse.org/show_bug.cgi?id=1184069#c9 --- Comment #9 from Ulrich Windl --- 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. -- You are receiving this mail because: You are on the CC list for the 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 --- 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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1184069 http://bugzilla.opensuse.org/show_bug.cgi?id=1184069#c13 --- Comment #13 from Ulrich Windl --- 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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1184069 Andreas Stieger changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Bootloader |Bootloader Version|Leap 15.2 |Current Product|openSUSE Distribution |openSUSE Tumbleweed -- You are receiving this mail because: You are on the CC list for the bug.