Bug 56593 - systemd-cryptsetup does not allow a hash type of "plain"
Summary: systemd-cryptsetup does not allow a hash type of "plain"
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-10-31 00:59 UTC by Will
Modified: 2012-11-06 14:53 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Attachments

Description Will 2012-10-31 00:59:46 UTC 
Running systemd-cryptsetup with "hash=plain" in the fifth (comma-delimited) parameter for a plain dm-crypted disk yields the error message "Failed to activate: Invalid argument." 

Replacing "plain" with "ripemd160" or another supported hash function works as expected. Removing the hash open from the list entirely just causes the default hash type to be used (in my case, ripemd160). 

This contradicts the crypttab and cryptsetup man pages. crypttab defers to the cryptsetup page for supported values of "hash," and cryptsetup mentions (albeit closer to the bottom of the page, under "NOTES ON PASSPHRASE PROCESSING FOR PLAIN MODE") that "if 'plain' is used as argument to --hash, the input data  will  not  be hashed," which implies that plain is a valid option.

Indeed, without supporting plain as an option, any disks or partitions set up initially with cryptsetup using --key-file=/myfile.key (for plain dm-crypt and not LUKS) do not seem to be decrypt-able, as cryptsetup will not apply a hash to the key in this instance, but systemd-cryptsetup must apply the hash.
Comment 1 Will 2012-10-31 01:04:08 UTC 
This bug is loosely related to this one: https://bugs.freedesktop.org/show_bug.cgi?id=52630

...but mine points out the lack of actual expected functionality.
Comment 2 Dave Reisner 2012-11-06 05:35:28 UTC 
Works for me:

# dd if=/dev/urandom of=/mykey bs=256 count=1
# cryptsetup create --key-file=/mykey -s 256 --cipher=aes-cbc-essiv:sha256 --hash=plain home /dev/vdd
# echo 'home  /dev/vdd  /mykey  hash=plain,cipher=aes-cbc-essiv:sha256,size=256' >>/etc/crypttab
# systemctl daemon-reload
# systemctl start systemd-cryptsetup@home.service
# systemctl status systemd-cryptsetup@home.service
systemd-cryptsetup@home.service - Cryptography Setup for home
          Loaded: loaded (/etc/crypttab)
          Active: active (exited) since Tue, 2012-11-06 00:22:35 EST; 3s ago
            Docs: man:systemd-cryptsetup@.service(8)
                  man:crypttab(5)
         Process: 938 ExecStart=/usr/lib/systemd/systemd-cryptsetup attach home /dev/vdd /mykey hash=plain,cipher=aes-cbc-essiv:sha256,size=256 (code=exited, status=0/SUCCESS)
          CGroup: name=systemd:/system/systemd-cryptsetup@.service/home

Nov 06 00:22:35 beatbox systemd[1]: Starting Cryptography Setup for home...
Nov 06 00:22:35 beatbox systemd[1]: Started Cryptography Setup for home.
Comment 3 Dave Reisner 2012-11-06 06:09:10 UTC 
Hmm... does not work for me after a reboot unless I invoke cryptsetup again to create another volume. Will need to look into this more later...
Comment 4 Dave Reisner 2012-11-06 14:53:52 UTC 
Fixed in git. The problem is that cryptsetup, on the front end, converts hashtype "plain" to a NULL params.hash argument in passing to crypt_format.

systemd-cryptsetup didn't do this, so it tried to pass an invalid hash to the libcryptsetup backend.

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.