[systemd-bugs] [Bug 56593] New: systemd-cryptsetup does not allow a hash type of "plain"

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=56593

          Priority: medium
            Bug ID: 56593
          Assignee: systemd-bugs at lists.freedesktop.org
           Summary: systemd-cryptsetup does not allow a hash type of
                    "plain"
        QA Contact: systemd-bugs at lists.freedesktop.org
          Severity: normal
    Classification: Unclassified
                OS: Linux (All)
          Reporter: a08198uym0921c0981 at mailinator.com
          Hardware: x86-64 (AMD64)
            Status: NEW
           Version: unspecified
         Component: general
           Product: systemd

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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-bugs/attachments/20121031/1a48d4ce/attachment.html>