You are not logged in.
Pages: 1
I have a fresh install of arch with /boot (encrypted because it's on the same partition as root), and /efi (unencrypted).
It takes ~5s when "Attempting to decrypt master key".
Is it possible to reduce the decrypt time to ~2s? Should I have /boot unencrypted?
I have random.trust_cpu=on in my GRUB_CMDLINE_LINUX.
Device Start End Sectors Size Type
/dev/nvme0n1p1 2048 534527 532480 260M EFI System
/dev/nvme0n1p2 534528 567295 32768 16M Microsoft reserved
/dev/nvme0n1p3 567296 128112639 127545344 60.8G Microsoft basic data
/dev/nvme0n1p4 496021504 500117503 4096000 2G Windows recovery environment
/dev/nvme0n1p5 128112640 496021503 367908864 175.4G Linux filesystem$ systemd-analyze
Startup finished in 8.841s (firmware) + 54.149s (loader) + 5.057s (kernel) + 2.664s (userspace) = 1min 10.712s
graphical.target reached after 2.664s in userspace.
$ systemd-analyze blame
795ms NetworkManager.service
621ms dev-mapper-vg\x2droot.device
272ms systemd-udev-trigger.service
253ms systemd-remount-fs.service
235ms systemd-modules-load.service
233ms systemd-tmpfiles-setup.service
201ms efi.mount
158ms modprobe@fuse.service
142ms user@1000.service
128ms lvm2-monitor.service
126ms modprobe@drm.service
112ms systemd-tmpfiles-setup-dev-early.service
...$ cryptsetup luksDump /dev/nvme0n1p5
LUKS header information for /dev/nvme0n1p5
Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha512
Payload offset: 4096
MK bits: 512
MK digest: 64 08 f8 ea b9 6a 52 15 4d 33 22 d0 6a 80 70 23 a3 eb c8 62
MK salt: 5e ca 05 df 17 64 61 99 55 18 fe ba 0b b6 ae 47
10 dd c1 d0 b3 7b 6f 6c 9d d2 3d 38 21 21 11 43
MK iterations: 303758
UUID: a8bdc8af-87b6-4abc-849b-83c4031d7456
Key Slot 0: DISABLED
Key Slot 1: ENABLED
Iterations: 6668208
Salt: d5 07 03 8d cb cd ee 76 15 72 7a 6a f5 a3 49 ab
69 d6 20 54 bd 8b b5 aa b3 ed d4 49 10 72 5b 8b
Key material offset: 512
AF stripes: 4000
Key Slot 2: ENABLED
Iterations: 1966080
Salt: a6 98 e3 54 f2 58 95 e5 fb f8 2a 99 37 9d 92 9c
65 f5 fe 9e d7 cd bb c4 65 87 3e 05 52 73 d6 97
Key material offset: 1016
AF stripes: 4000$ cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1 3163125 iterations per second for 256-bit key
PBKDF2-sha256 6452775 iterations per second for 256-bit key
PBKDF2-sha512 2421653 iterations per second for 256-bit key
PBKDF2-ripemd160 1267927 iterations per second for 256-bit key
PBKDF2-whirlpool 1012138 iterations per second for 256-bit key
argon2i 8 iterations, 1048576 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id 8 iterations, 1048576 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 1763.5 MiB/s 6501.5 MiB/s
serpent-cbc 128b 122.1 MiB/s 846.5 MiB/s
twofish-cbc 128b 262.8 MiB/s 546.0 MiB/s
aes-cbc 256b 1390.3 MiB/s 5400.7 MiB/s
serpent-cbc 256b 124.7 MiB/s 842.3 MiB/s
twofish-cbc 256b 267.3 MiB/s 552.3 MiB/s
aes-xts 256b 5111.5 MiB/s 5101.4 MiB/s
serpent-xts 256b 738.2 MiB/s 757.2 MiB/s
twofish-xts 256b 511.5 MiB/s 517.9 MiB/s
aes-xts 512b 4630.5 MiB/s 4615.5 MiB/s
serpent-xts 512b 751.3 MiB/s 766.0 MiB/s
twofish-xts 512b 516.4 MiB/s 520.8 MiB/sLast edited by ArchGuest24 (2023-09-16 12:48:55)
Offline
Please edit your post and use [ code ] tags (not quote tags) when posting output. This makes the output easier to read and provides a scroll box for long output.
https://wiki.archlinux.org/title/Genera … s_and_code
https://bbs.archlinux.org/help.php#bbcode
Offline
Grub is known to be slow when decrypting. That's just how it is, if you don't like it, go with unencrypted bootloader + kernel + initrd. You can still encrypt everything else.
Also, you have two keyslots. Make sure you put the passphrase for Grub into the first one; otherwise Grub will have to try both, which takes twice as long. Same for encrypt hook in initramfs; if it has to try both keyslots, it will take longer than strictly necessary.
Another way to make Grub cryptodisk faster is to drastically reduce the iteration counts. However this means you lose the bruteforce protection that LUKS normally offers. It's not safe without a very high entropy passphrase.
Offline
Pages: 1