plain block encrypted drive fails to decrypt with crypttab

kristopher004 · 2014-08-29 16:20:35

I can't figure this out. I have a plain dm-crypt full disk encryption. I made a test key like this:

dd if=/dev/random of=/test.key bs=1 count=64

I mount it manually with:

cryptsetup --hash=sha512 --cipher=aes-xts-plain64 --key-file=/test.key --key-size=512 --type=plain open /dev/sdx test-crypt

then I format the drive and mount it (mkfs.btrfs /dev/mapper/test-crypt && mount /dev/mapper/test-crypt /mnt), unmount and close with cryptsetup close test-crypt, then decrypt again and it mounts just fine. However if I had this entry to crypttab:

test-crypt /dev/sdx /test.key hash=sha512,cipher=aes-xts-plain64,size=512,plain

then after boot it decrypts, but no longer has a filesystem. I can close it with cryptsetup and manualy mount it again, and then the filesystem is back. If I run cryptsetup status test-crypt the status is identical for both methods. The only way I got it to work is to manually decrypt with a short passphrase, such as 'test', then add a crypttab

test-crypt /dev/sdx none hash=sha512,cipher=aes-xts-plain64

and enter the passphrase at boot, it decrypts and works as expected. Anyone know what I'm missing? or have had this problem?

Last edited by kristopher004 (2014-08-31 17:03:33)

Strike0 · 2014-08-29 20:22:02

Did you create n fstab entry for it?

Other than that it could be It's not you missing something, but that happens due to an old missed-out systemd bug: it processes crypttab options wrong for plain devices. Try the following: create a key-file with "count=512" and create your blockdevice like this:

# /usr/lib/systemd/systemd-cryptsetup attach test-crypt /dev/sda6 /test.key cipher=aes-xts-plain64,size=512,hash=sha512,plain

format it again and see if that works with your crypttab line.

kristopher004 · 2014-08-29 23:53:29

 # /usr/lib/systemd/systemd-cryptsetup attach test-crypt /dev/sda6 /test.key cipher=aes-xts-plain64,size=512,hash=sha512,plain

This works, I attached with this line, formatted and rebooted and crypttab decrypted the drive successfully.

This cryptsetup line still fails to decrypt the drive though:

#cryptsetup --hash=sha512 --cipher=aes-xts-plain64 --key-file=/test.key --key-size=512 --type=plain open /dev/sdx test-crypt

I guess systemd-cryptsetup and cryptsetup just aren't compatible?

Strike0 · 2014-08-30 07:43:47

Well, systemd does not process the crypttab plain options to the key-file correctly to the spec. Maybe it has to do with how the key-file is parsed or how systemd applies the hash to it. Clearly a bug; systemd wants to support the cryptsetup features for plain devices.

Thinking about it now, the real problem with it is that one cannot be certain that the bug does not affect the cryptographic quality of the plain device (created with systemd-cryptsetup).

So, if you intend to use a plain device as secondary mount like this (non-boot with crypttab), it would be better to leave crypttab out the boot process for plain devices really until it works like it should. For a plain device that's easy: All you would have to do is to create a service calling a script that itself opens with "# cryptsetup -type plain open ....." and mounts it. (Normal systemd logic should handle unmounting on shutdown automatically; I'm not sure about suspend-resume though).

kristopher004 · 2014-08-30 15:09:40

Okay, so trust cryptsetup over systemd-cryptsetup. Do you happen to know how to use --keyfile-offset?

 # cryptsetup ... --keyfile-offset=...

returns

Ignoring keyfile offset and size options, keyfile read size is always the same encryption key size.

The reason I ask is because I wanted to save my keys as a bit stream on on usb key. I have already tested this with the kernel command line option cryptkey=device:offset:size, but I can't seem to get it to work with cryptsetup.

Strike0 · 2014-08-30 23:13:32

Further to the last point: imagine the "systemd-cryptsetup" gets fixed for the issue sometime, it will break your access to the device.

Please quote the full "cryptsetup open" statement that fails with the offset.

kristopher004 · 2014-08-30 23:19:24

Here is the full statment:

 cryptsetup --hash=sha512 --cipher=aes-xts-plain64 --key-file=/dev/sdb --key-size=512 --keyfile-offset=1000 --type=plain open /dev/sda test-crypt

and that returns:

 Ignoring keyfile offset and size options, keyfile read size is always the same as encryption key size

It doesn't seem like the keyfile offset works with any type of plain encryption, I haven't tried luks.

Strike0 · 2014-08-31 13:17:25

Thanks, but now I believe you focus on the next bug , this time in cryptsetup.
The commit introducing that error message appears pretty old. Recently (June) the --keyfile-offset option was fixed for loopaes, maybe similar can be done for plain devices. I searched but did not find a bug-report, so I think you should seek help on the cryptsetup mailing list or report the options "--keyfile-offset" and "--keyfile-size" as buggy for plain devices here: https://code.google.com/p/cryptsetup/issues/list

Please post a reference here, once you report it. Thanks.

Thinking about a way to work around, I ended up doing something similar to the Arch encrypt hook (using offset):

#!/bin/bash
## Work around for bugs in --keyfile-offset and --keyfile-size options in cryptsetup 1.6.5
## /dev/sdy is used as a bitstream keyfile device; /dev/sdx contains the plain mode blockdevice; adjust as required

cryptsetup close test-crypt && cryptsetup close key-file
echo "test-crypt" | cryptsetup -v --hash=sha256 --cipher=aes-xts-plain64 --key-size=512 --offset=2 --skip=2 -d - --type=plain open /dev/sdy key-file 
cryptsetup -v --hash=sha256 --cipher=aes-xts-plain64 --key-file=/dev/mapper/key-file --key-size=512 --type=plain open /dev/sdx test-crypt 
mkfs -t ext4 /dev/mapper/test-crypt 
cryptsetup close test-crypt && cryptsetup close key-file 
## to test it:
dd if=/dev/urandom of=/dev/sdy bs=100 count=1 
echo "test-crypt" | sudo cryptsetup -v --hash=sha256 --cipher=aes-xts-plain64 --key-size=512 --offset=2 --skip=2 -d - --type=plain open /dev/sdy key-file 
cryptsetup -v --hash=sha256 --cipher=aes-xts-plain64 --key-file=/dev/mapper/key-file --key-size=512 --type=plain open /dev/sdx test-crypt 
mount /dev/mapper/test-crypt /mnt
ls /mnt
umount /mnt 
cryptsetup close test-crypt && cryptsetup close key-file

If you use a file as key-file, you can do a similar offset with "losetup".

kristopher004 · 2014-08-31 14:27:12

Oh I like this. So assuming the flashdrive has 512 byte sectors this will use a encrypted 512 bit key 1024 bytes into the flash drive, and 1024 bytes into decrypted device. And we could use the --size option to limit the encrypted device so we can still put a partition table on the flash drive a little ways in. Oh the convoluted glory, I Love it.

I took a look at the mailing list, the fourth comment in issue 7 made me lol

Last edited by kristopher004 (2014-08-31 14:31:35)

Strike0 · 2014-08-31 15:44:42

Yes, funny statement in comment four, but that bug tracker issue you refer to is about luks and not plain mode. "--keyfile-offset" should either work for plain or be removed from the manual for it.

kristopher004 · 2014-08-31 15:48:22

Agreed, especially because in man entry it specifically says it should work for anything that uses a keyfile. I'm setting up a systemd service to go along with a script based on your workaround now, I'll post them here once I get them working.

frostschutz · 2014-08-31 16:04:10

Strike0 wrote:

Thinking about it now, the real problem with it is that one cannot be certain that the bug does not affect the cryptographic quality of the plain device (created with systemd-cryptsetup).

You can have a look at what was created using dmsetup.

dmsetup table --showkeys

This output also gives you access to your device (echo the crypt line | dmsetup create name) so that's a possibility if you worry about systemd-cryptsetup making some incompatible change.

As for keyfile offsets, I'm using them with LUKS, works for me...

kristopher004 · 2014-08-31 16:17:14

Okay I did a quick test, I made a keyfile:

 # dd if=/dev/urandom of=/tmp/tmp.key bs=1 count=64

Then mounted with systemd-cryptsetup:

 # /usr/lib/systemd/systemd-cryptsetup attach test-crypt /dev/sdc /tmp/tmp.key plain,hash=sha512,cipher=aes-xts-plain64,size=512

Then checked the dmsetup table

# dmsetup table --showkeys
.
.
.
test-crypt: 0 3907029168 crypt aes-xts-plain64 db0b732fd472449f52f5c720fd99ff6c4731d3646b7024739d608b3a72714e5c3ab501e52a349852d6f0924d8f447a5f9585ec6856cac343194af658649ec557 0 8:32 0

Then repeated with cryptsetup:

# cryptsetup --hash=sha512 --cipher=aes-xts-plain64 --key-file=/tmp/tmp.key --key-size=512 --type=plain open /dev/sdc test-crypt
# dmsetup table --showkeys
.
.
.
test-crypt: 0 3907029168 crypt aes-xts-plain64 18c5ee078bbb716c077814a64966a632e0be8aa6306fd75426f726f750a8615ee8f03617693917f75d66288ac5be9a8fd6ab52856d115634dce5770fd4635f25 0 8:32 0

The keys are different, so systemd-cryptsetup is hashing the keys differently?

kristopher004 · 2014-08-31 16:25:38

Okay, one more quick test showed what might be the problem, I decrypted the drives again but this time I changed the hash:

# /usr/lib/systemd/systemd-cryptsetup attach test-crypt /dev/sdc /tmp/tmp.key plain,hash=sha1,cipher=aes-xts-plain64,size=512
# dmsetup table --showkeys
.
.
.
test-crypt: 0 3907029168 crypt aes-xts-plain64 63e7ec8bc192d3d61f529f9e3ab701fdcb12e2a7833acca8d1202c82bd5c3fb0f94434d48cb9ab924b35cb3f20d8345bdd209ce9e0a61913530d5dbd2efffc61 0 8:32 0
# cryptsetup close test-crypt
# cryptsetup --hash=sha1 --cipher=aes-xts-plain64 --key-file=/tmp/tmp.key --key-size=512 --type=plain open /dev/sdc test-crypt
# dmsetup table --showkeys
.
.
.
test-crypt: 0 3907029168 crypt aes-xts-plain64 18c5ee078bbb716c077814a64966a632e0be8aa6306fd75426f726f750a8615ee8f03617693917f75d66288ac5be9a8fd6ab52856d115634dce5770fd4635f25 0 8:32 0

So, the systemd-cryptsetup key changed when I changed the hash, but the cryptsetup key did not. So cryptsetup is ignoring the --hash flag??

Last edited by kristopher004 (2014-08-31 16:26:34)

kristopher004 · 2014-08-31 16:52:20

Okay, without both of you guys I would never have figured this out. So cryptsetup is not hashing the keys when they are given as a keyfile, instead I passed them as a passphrase like strike0 did in his workaround above (I added -n flag to get ride of the new line after echo):

# echo -n "`cat /tmp/tmp.key`" | sudo cryptsetup --cipher=aes-xts-plain64 --hash=whirlpool -d - --key-size=512 --type=plain open /dev/sdc test-crypt
# dmsetup table --showkeys
. 
.
.
test-crypt: 0 3907029168 crypt aes-xts-plain64 c15933cb2f3dfd1783c250497013f5f2137d3d4cb0aa28a8aa646b95a845b1391b8f662ed7a92c8493a60a0594e1669a2ff94a7046a5441f7545409b3c3d4360 0 8:32 0
# cryptsetup close test-crypt
# /usr/lib/systemd/systemd-cryptsetup attach test-crypt /dev/sdc /tmp/tmp.key plain,hash=whirlpool,cipher=aes-xts-plain64,size=512
# dmsetup table --showkeys
.
.
.
test-crypt: 0 3907029168 crypt aes-xts-plain64 c15933cb2f3dfd1783c250497013f5f2137d3d4cb0aa28a8aa646b95a845b1391b8f662ed7a92c8493a60a0594e1669a2ff94a7046a5441f7545409b3c3d4360 0 8:32 0

worked

teateawhy · 2014-08-31 18:31:51

kristopher004 wrote:

echo "`cat`" |

You managed to misuse both echo and cat at once
http://en.wikipedia.org/wiki/Cat_(Unix) … use_of_cat

kristopher004 · 2014-08-31 18:42:27

Thanks for the info lol, so would the non UUOC way to do it be like this?

</tmp/tmp.key echo | sudo crypt...

Strike0 · 2014-08-31 22:02:11

kristopher004 wrote:

So cryptsetup is not hashing the keys when they are given as a keyfile, instead I passed them as a passphrase like strike0 did in his workaround above (I added -n flag to get ride of the new line after echo):

That's a great test you did there using the dmsetup command from frostschutz! And for the result of your comparison:

man cryptsetup wrote:

--hash, -h <hash-spec>
Specifies the passphrase hash for open (for plain and loopaes
device types).

suggests that "systemd-cryptsetup" hashes a keyfile when it should not and any plain mode devices using a keyfile in crypttab are bound to fail on next boot.
edit: to clarify

Last edited by Strike0 (2014-09-01 11:02:17)

float · 2014-12-10 21:09:39

Has anyone filed a bug report about this?
systemd-cryptsetup clearly should not hash the content of the keyfile in plain mode.
I actually do not know why we have systemd-cryptsetup in the first place.
Why doesn't the hook (or the systemd service) just use cryptsetup?
Edit: See https://wiki.archlinux.org/index.php/Dm … n#crypttab and https://bugs.debian.org/cgi-bin/bugrepo … bug=768577
It seems Zbigniew does not (want to?) understand what the problem is.
The manual *does* clearly state that keyfiles are not hashed in plain mode.

Anyway: The solution is to add the hash=plain option to crypttab.

Last edited by float (2014-12-10 22:02:24)

starfry · 2014-12-16 13:57:43

+1 for this. Thank you very much @float for clearly stating an appropriate work-around.

I've just been reading the upstream bug report (https://bugs.freedesktop.org/show_bug.cgi?id=52630) and I also think Zbigniew misunderstands. The cryptsetup docs are quite clear in how it works; I've had my nose in the cryptsetup code a fair bit recently and the docs do indeed reflect reality: hashing is performed on passphrases only.

In plain mode a "key-file" contains a key, not a pass phrase (this is different to LUKS mode, where a key file does in fact contain a pass phrase). The concept of a "hash" in cryptsetup plain mode is only relevant when a user manually enters a "pass phrase". In that scenario the "pass phrase" is "hashed" to produce a "key" to unlock the volume.

The configuration of crypttab follows suit, but, when systemd is involved, it's interpreted differently. Surely the origin (i.e. cryptsetup) should be the definition of what is correct...

Arch Linux

#1 2014-08-29 16:20:35

plain block encrypted drive fails to decrypt with crypttab

#2 2014-08-29 20:22:02

Re: plain block encrypted drive fails to decrypt with crypttab

#3 2014-08-29 23:53:29

Re: plain block encrypted drive fails to decrypt with crypttab

#4 2014-08-30 07:43:47

Re: plain block encrypted drive fails to decrypt with crypttab

#5 2014-08-30 15:09:40

Re: plain block encrypted drive fails to decrypt with crypttab

#6 2014-08-30 23:13:32

Re: plain block encrypted drive fails to decrypt with crypttab

#7 2014-08-30 23:19:24

Re: plain block encrypted drive fails to decrypt with crypttab

#8 2014-08-31 13:17:25

Re: plain block encrypted drive fails to decrypt with crypttab

#9 2014-08-31 14:27:12

Re: plain block encrypted drive fails to decrypt with crypttab

#10 2014-08-31 15:44:42

Re: plain block encrypted drive fails to decrypt with crypttab

#11 2014-08-31 15:48:22

Re: plain block encrypted drive fails to decrypt with crypttab

#12 2014-08-31 16:04:10

Re: plain block encrypted drive fails to decrypt with crypttab

#13 2014-08-31 16:17:14

Re: plain block encrypted drive fails to decrypt with crypttab

#14 2014-08-31 16:25:38

Re: plain block encrypted drive fails to decrypt with crypttab

#15 2014-08-31 16:52:20

Re: plain block encrypted drive fails to decrypt with crypttab

#16 2014-08-31 18:31:51

Re: plain block encrypted drive fails to decrypt with crypttab

#17 2014-08-31 18:42:27

Re: plain block encrypted drive fails to decrypt with crypttab

#18 2014-08-31 22:02:11

Re: plain block encrypted drive fails to decrypt with crypttab

#19 2014-12-10 21:09:39

Re: plain block encrypted drive fails to decrypt with crypttab

#20 2014-12-16 13:57:43

Re: plain block encrypted drive fails to decrypt with crypttab

Board footer