Bug 52630 - systemd-cryptsetup handles keyfile differently from cryptsetup on plain mode
Summary: systemd-cryptsetup handles keyfile differently from cryptsetup on plain mode
Status: RESOLVED FIXED
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: systemd-bugs
QA Contact: systemd-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-29 02:18 UTC by Marcos
Modified: 2015-05-24 15:09 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Proposed patch (1.29 KB, patch)
2014-11-19 11:14 UTC, Quentin Lefebvre
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Marcos 2012-07-29 02:18:05 UTC
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
Comment 1 Leho Kraav (:macmaN :lkraav) 2013-09-05 07:54:43 UTC
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.
Comment 2 Quentin Lefebvre 2014-11-18 15:03:31 UTC
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
Comment 3 Quentin Lefebvre 2014-11-19 11:14:04 UTC
Created attachment 109722 [details] [review]
Proposed patch
Comment 4 Quentin Lefebvre 2014-11-19 11:15:59 UTC
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
Comment 5 Zbigniew Jedrzejewski-Szmek 2014-11-24 14:19:46 UTC
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.
Comment 6 Quentin Lefebvre 2014-11-24 14:40:03 UTC
Hi,

I agree with you.

Thanks for pushing this patch and making it a bit more elegant.

Best,
Quentin
Comment 7 Quentin Lefebvre 2014-11-24 17:50:45 UTC
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
Comment 8 Zbigniew Jedrzejewski-Szmek 2014-11-24 18:28:35 UTC
Sorry, but this is wrong place to fix the issue.
Comment 9 Quentin Lefebvre 2014-11-25 10:56:05 UTC
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
Comment 10 Zbigniew Jedrzejewski-Szmek 2014-12-01 01:23:41 UTC
(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.
Comment 11 Leho Kraav (:macmaN :lkraav) 2015-02-11 00:21:20 UTC
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.
Comment 12 Joachim Zobel 2015-05-24 11:25:58 UTC
+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.
Comment 13 Zbigniew Jedrzejewski-Szmek 2015-05-24 15:09:12 UTC
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.