LuksResume with key on partition

Hello,

I have copied my key to /dev/sdc3 using dd

The key size is 152bytes or 1216bits.

Then I luksSuspend and try to resume with

cryptsetup luksResume -d /dev/sdc3 -s 1216 safe
but I get "No key available with this passphrase"

If I don't specify a size then I get a warning about
Warning: exhausting read requested, but key file /dev/sdc3 is not a regular file, function might never return.

I have also tried -s 152

To get around this in cryptab I use
keyscript=/key.sh

where key.sh

dd bs=1 count=1217 if=$1

Why must equal count=1217??

I have hexdump and diffed them they are the same for the first 1216 bits

I also set all the remaining bits on the partition to 00 using dd.

Please assist!

First, why are you not using file but whole partition?

With file you do not need to use -s.

(See man page, read is exhausting for key, so
it tries use the while device.)

-s takes size in bits (multiple of 8 bits only), so 1216.

This works for me.

Isn't there \n in the end of passphrase? The same syntax for luksOpen should work for luksResume.

See man page "notes on password processing".

(Also check --debug output, maybe there is some more info.)

Milan

First let me thank you for you prompt reply.

The file is not available because the disk is not mounted. I access it in cryptab with /dev/disk/by-id/usb-TOSHIBA_TransMemory_001D92DC4AF0C97093A20E53-0:0-part3

I used size to stop an exhaustive read.

Yep

No way, really?

I am using cryptsetup 2:1.1.0-2.1 from debian
I tried to get the cvs but cant dig cvs.saout.de (not even from saout.de ns)?????

Luksopen gets called through keyscript and key.sh mechanism. (which was a hakaround for this problem) but it only works in cryptab.

Ok .

Will do. I will also try the CVS version. and contact the PM at debland.

http://code.google.com/p/cryptsetup/
(where do you get that old cvs address?)

try 1.1.1-rc2 please and if it doesn't work, I need some reproducer (I tried simple passphrase and it works here, I think I even used 1.1.0 for test)

Milan

Hi Milan,

From www.saout.de. - is this an old dead site?

I don't have a spare disk handy (perhaps tonight I can try) - so I tried with loops, but it fails with

"Device /dev/loop4 is not a valid LUKS device."

Should it work with loops in this way? Have I done something wrong in my script?

libdevmapper1.02.1 2:1.02.45-1

PATH=/usr/sbin/:$PATH
cryptsetup --version
rm key test.disk /mnt/hello
dd if=/dev/urandom of=key count=1216
dd if=/dev/urandom of=test.disk count=2048
losetup -d /dev/loop4
losetup -d /dev/loop5
losetup /dev/loop4 test.disk
losetup /dev/loop5 key
losetup -a
echo setup loops
cryptsetup -c aes-plain -h sha512 -b 2048 create test /dev/loop4 -d key cryptsetup status test
echo setup mapper
mkfs.ext2 /dev/mapper/test
mount /dev/mapper/test /mnt/
touch /mnt/hello
echo "hello" > /mnt/hello
sync
umount /mnt
echo setup filesystem
cryptsetup status test
cryptsetup remove test
cryptsetup -d /dev/loop5 -s 1216 luksOpen /dev/loop4 test mount /dev/mapper/test /mnt
cat /mnt/hello
umount /mnt
cryptsetup luksClose test

No, but svn and project page is now on Google code site. There is lot of old information on wiki seems (But IIRC link to cryptsetup page was updated. Strange.)

luksSuspend/Resume is supported on LUKS devices only, it will be never supported for plain devices (there is no way how to verify the passphrase is correct, it can lead to data corruption.)

Instead of

you have to use
cryptsetup luksFormat /dev/loop4 key

then
cryptsetup luksOpen /dev/loop4 -d key

Keep default cipher better, not sure why are you using known-IV vulnerable mode here...

Milan

hmmm. It now works..

I seem to have miscalculated a factor of 8 somewhere, the correct size of my key was 1216bytes=9728bits

I also had to change lib/utils.c to

483c483
< for(i = 0; read_horizon == 0 || i <= read_horizon; i++) {
---

Will this patch break other keys???

.. Now I can use the following udev rule

DRIVERS=="usb" ACTION=="remove" SUBSYSTEM=="usb", ENV{ID_SERIAL_SHORT}=="001D", RUN+="/usr/bin/xscreensaver-command -display :0.0 -lock" DRIVERS=="usb" ACTION=="remove" SUBSYSTEM=="usb", ENV{ID_SERIAL_SHORT}=="001D", RUN+="/sbin/cryptsetup luksSuspend safe"

DRIVERS=="usb" ACTION=="add" SUBSYSTEM=="usb", ENV{ID_SERIAL_SHORT}=="001D", RUN+="/usr/bin/xscreensaver-command -display :0.0 -deactivate" DRIVERS=="sd" ACTION=="add" SUBSYSTEM=="block", ENV{ID_SERIAL_SHORT}=="001D", RUN+="/usr/sbin/cryptsetup luksResume safe -d /dev/%k -s 9728"

This seems wrong to me. It will read one byte more than expected, why?

Do you have reproducer where it fails? If so, send me the exact commands which fails here (including example of failing key file).

Properly set -s should work here without the patch.

hmmm. it is interesting idea, but running such commands directly from udev is probably not ideal (not even supported).

Luckily, Suspend/resume do not depend on udev sync, so maybe
it works in this case. But luksOpen and luksCLose can deadlock here waiting for itself)

"add" event means, that new device object was added to system. But it doesn't mean that device is ready to use - it probably will work for usb device, but only because they send event after initialization.

(I was surprised that is is implemented that way, but it is. "add" means you can try scan device, but it can fail and you should retry on next change event...)

IOW read of key can fail. It should react to first add or change event (only if device is suspended). Again, maybe it works in this case, but not in other.

Anyway, I think this should be done from some widget listening on system bus (or using libudev) not in udev rules.

Milan