Description of problem: when I upgrade to Fedora 34 from F33 by dnf && first startup, it stop running at unlocking luks partition if keyfile > 1024*4096-1 bytes(4.0MiB), the cmd: /usr/lib/systemd/systemd-cryptsetup attach <name> <path> <keyfile path> <args> return: Failed to activate with key file "<keyfile path>": Invalid argument Version-Release number of selected component (if applicable): F34.{AARCH64,X86_64} systemd-248.3-1.fc34 How reproducible: Steps to Reproduce: 1.make keyfile dd if=/dev/urandom of=./keyfile.n bs=1 count=4194304 2.make keyfile dd if=/dev/urandom of=./keyfile.y bs=1 count=4194303 3.format a luks partition && add key cryptsetup luksFormat /dev/<path> ./keyfile.n cryptsetup luksAddKey /dev/<path> ./keyfile.y -d ./keyfile.n (cryptsetup can use keyfile that >= 4MiB format && unlock partition) 4.edit /etc/crypttab, add <keyfile.n path> (is better to add "noauto" args) 5.reboot 6.try start "systemctl start systemd-cryptsetup@<luks name>" && check "systemctl status systemd-cryptsetup@<luks name>" Actual results: service inactive && return msg: Failed to activate with key file "<keyfile path>": Invalid argument Expected results: service active Additional info: in F33 Even if the keyfile >= 1024*4096 bytes /usr/lib/systemd/systemd-cryptsetup attach can work normally in F34 only keyfile <= 1024*4096-1 bytes systemd-cryptsetup can work once keyfile more then 4MiB it say Failed to activate with key file "<keyfile path>": Invalid argument
If you directly run "cryptsetup open --key-file ..." does it work correctly? If so, it seems that systemd should use uint64 for keyfile size somewhere...
(In reply to Milan Broz from comment #1) > If you directly run "cryptsetup open --key-file ..." does it work correctly? > > If so, it seems that systemd should use uint64 for keyfile size somewhere... cryptsetup work correctly~ should I change Component from cryptsetup to systemd??
Looking in current systemd code in git the problem seems to be that without key size set explicitly, the systemd process by default up to 4MB (-1 byte) whereas cryptsetup cli processes by default up to 8MB. You can workaround the issue immediately by setting keyfile-size= in your crypttab. If you set size explicitly systemd won't apply said default limit. On the other hand I do not understand why LUKS key passphrase should be this large. The MEK itself in LUKS is 256bits (x2 with xts mode) by default, so why don't stick with cryptographic strong KEK put in file instead with reasonable size? I don't think you gain anything by using such monstrous KEK. Just my 2 cents
(In reply to Ondrej Kozina from comment #3) > Looking in current systemd code in git the problem seems to be that without > key size set explicitly, the systemd process by default up to 4MB (-1 byte) > whereas cryptsetup cli processes by default up to 8MB. > > You can workaround the issue immediately by setting keyfile-size= in your > crypttab. If you set size explicitly systemd won't apply said default limit. > > On the other hand I do not understand why LUKS key passphrase should be this > large. The MEK itself in LUKS is 256bits (x2 with xts mode) by default, so > why don't stick with cryptographic strong KEK put in file instead with > reasonable size? I don't think you gain anything by using such monstrous KEK. > > Just my 2 cents First of all,thank you~ after adding this arg, the keyfile can be read correctly now. Regarding your question about whether the keyfile is to large is necessary. I think of it this way: the keyfile may not necessarily be specially generated,it may also be a randomly selected file that has other functions but will not be modified?(E.g:RaspberyPI boot file like start4.elf) may be... it is possible that a file larger than 4MiB happens to be selected? Anyway,thanks for helping me with this problem,Thanks~
... for the sake of security: > the keyfile may not necessarily be specially generated,it may also be a > randomly selected file that has other functions but will not be > modified?(E.g:RaspberyPI boot file like start4.elf) This is VERY bad approach if it is file that is a common part of distribution. I guess bruteforce of such keyfiles is possible in hours... With PBKDF2 used in LUKS1 it is even worse as it can be easily run in parallel and also you can pre-hash keyfiles in some db (hash of the big keyfile will unlock the volume). https://en.wikipedia.org/wiki/PBKDF2#HMAC_collisions With Argon2 KDF (used in LUKS2) you cannot optimize it this way, though, but still, better use randomly generated keyfiles. Just saying... the limit should be fixed anyway :)
Fixed in rawhide.
Upstream issue: https://github.com/systemd/systemd/issues/19193. I'll backport a simplified version of the patch for v248.6.
FEDORA-2021-3141f0eff1 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-3141f0eff1
FEDORA-2021-3141f0eff1 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-3141f0eff1` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-3141f0eff1 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-3141f0eff1 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.