Hi, cryptsetup handles keyfile for plain mode as follows (from man page) 1. if reading a keyfile via --keyfile switch, the content of the file will be used as key and only the needed bytes to fulfill the key size will be read. No hash is applied to contents of the keyfile 2. if reading from stdin (via --keyfile=- switch), the entire content of the file will be read and will also be hashed using the default hash algo or the one specified via --hash switch systemd-cryptsetup mixes the above two algos in just one,doing the following: - key size bytes will be read from keyfile (mode 1) and a hash will be applied on it(mode 2) This makes it difficult to use crypttab+systemd-cryptsetup on disks encrypted using plain mode from cryptsetup. Examples: dd count=10k bs=4k </dev/zero >container losetup /dev/loop0 container dd count=4 bs=512 </dev/urandom >key_file 1. cryptsetup -c aes-xts-plain -s 512 -h sha256 -d key_file create test /dev/loop0 mkfs.ext2 /dev/mapper/test mount /dev/mapper/test /mnt/test umount /mnt/test cryptsetup remove test /usr/lib/systemd/systemd-cryptsetup attach test /dev/loop0 key_file cipher=aes-xts-plain,size=512,hash=sha256 mount /dev/mapper/test /mnt/test Error: mount: wrong fs type, bad option, bad superblock on /dev/mapper/test, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so 2. cat key_file |cryptsetup -c aes-xts-plain -s 512 -h sha256 -d - create test Same error aforementioned happens. The only way to make it to work is to create a keyfile with exact the size of the key and use the syntax of example #2. But this is not the idea of having a keyfile, since one could use any file (of any size) as keyfile in example #2 using cryptsetup. My request would be to have systemd-cryptsetup handling keyfiles the same way cryptsetup does. Thank you, Marcos
I am also seeing strange behavior with a plain encryption device. Commandline cryptsetup works fine, but systemctl start causes device contents to be garbled which means some input is incorrect. Looking at this bug, it's indeed very likely the keyfile.
Hi, I just proposed a patch for this bug. I hope it will be soon taken into account. Waiting for this, you can make both cryptsetup and systemd-cryptsetup work by changing the 'hash' option in /etc/crypttab to 'hash=plain'. Best regards, Quentin
Created attachment 109722 [details] [review] Proposed patch
Please find the proposed patch attached above. Also additional information can be found here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768577 Best regards, Quentin
Hi, thank you for the report and the patch. It seems wrong to ignore the hash parameter if it is explicitly specified. Even if cryptsetup did that, it seems to be a bug in cryptsetup, and not something to be blindly followed. I changed the code to default to no hash if key file is specified though in http://cgit.freedesktop.org/systemd/systemd/commit/?id=8a52210c93.
Hi, I agree with you. Thanks for pushing this patch and making it a bit more elegant. Best, Quentin
Hi again, Sorry for that, but your patch doesn't solve the issue, as I mentionned in the mailing list: http://lists.freedesktop.org/archives/systemd-devel/2014-November/025490.html So I reopen the bug and kindly suggest you to apply my original patch, or find an equivalent way to make it work. Best regards, Quentin
Sorry, but this is wrong place to fix the issue.
Hi, I reopened (again) this bug report. Please read the following before getting angry... Actually, cryptsetup(8) makes it quite clear that hash processing is only used on *passphrases*. See the "NOTES ON PASSPHRASE PROCESSING FOR PLAIN MODE" section. So, IMHO that's not a bug in cryptsetup, but rather the intended and documented way it works. So, this means that, when a key file is provided, any provided hash algorithm should definitely be ignored (in plain mode). Thanks in advance to take that into account. Cheers, Quentin
(In reply to Quentin Lefebvre from comment #9) > Hi, > > I reopened (again) this bug report. Please read the following before getting > angry... Hi, sorry for my ternseness. I'm not angry, I'm trying to solve the problem in the best way, same as you. But I think we reached a point where the situation is clear, everything has been articulated clearly, and the differences stem only from different priorities, not misunderstanding. I understand that for you keeping current cryptsetup-compatible setups functional is more important, but for me sensible and consistent systemd behaviour is more important. More words will not help the issue. > Actually, cryptsetup(8) makes it quite clear that hash processing is only > used on *passphrases*. See the "NOTES ON PASSPHRASE PROCESSING FOR > PLAIN MODE" section. So, IMHO that's not a bug in cryptsetup, but > rather the intended and documented way it works. I read the man page (on Fedora, I'm not sure if it is the same) and while it's true that it talks about "passphrase processing", it also does not explictly say that hash will be ignored for a file. That section even talks about hashing input read from stdin, and also about reading stuff from a file. So even if cryptsetup ignores --hash when reading from a key file, it seems to be more by mistake then by design, at least when judging by the man page. As discussed on the ml, we'll keep current behaviour.
I would still consider this a WASABUG, rather than NOTABUG, since 8a52210c93 fixed my issue of /etc/crypttab simply not working with plain,cipher=aes-cbc-plain configuration at all. systemd-218 everything is smooth. tyvm sir.
+1 for WASABUG from me. This broke my system when moving from debian wheezy to jessie and I spend half a day finding this bug report and applying hash=plain. I am OK with not reimplementing what systemd-cryptsetup considers a bug in cryptsetup. But there should have been a big fat warning about an incosistency in crypttab instead.
OK, changing resoulution based on popular vote.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.