yOn Tuesday 2010-05-18 22:17, Stefan G. Weichinger wrote: > >I saved my history, unfortunately only the last steps were kept, but I >am able to reconstruct: > >The block-device is /dev/VG01/sgwcrypt ... > >#I tried a more complicated KEY >KEY=`head -c 79 /dev/urandom`
Well, I'm not going to blame you yet, but the shell is pretty binary-unsafe -- and you have just invoked that voodoo again. # head -c79 /dev/urandom >t-crypt.ukey; \ hexdump -C <t-crypt.ukey; \ KEY=$(cat t-crypt.ukey); \ echo -n "$KEY" | hexdump -C; \ echo -n "$KEY" | wc; 00000000 a4 b2 c8 a0 4f c9 00 37 66 f3 0c 20 2d 5c 05 e7 |....O..7f.. -\..| 00000010 cd 5e 5d 00 5d e1 18 2a 1a 8b 2d 41 22 e7 66 0e |.^].]..*..-A".f.| 00000020 b0 a3 1d 41 1e 23 1d 00 f8 b2 b2 bc 34 28 94 fe |...A.#......4(..| 00000030 ba 0f 45 11 b5 c6 d8 a1 ca c2 ec 08 5e 48 d4 7f |..E.........^H..| 00000040 17 a8 75 af ef ef f1 7a 0f 2f bf 64 c2 3a 9c |..u....z./.d.:.| 0000004f 00000000 a4 b2 c8 a0 4f c9 37 66 f3 0c 20 2d 5c 05 e7 cd |....O.7f.. -\...| 00000010 5e 5d 5d e1 18 2a 1a 8b 2d 41 22 e7 66 0e b0 a3 |^]]..*..-A".f...| 00000020 1d 41 1e 23 1d f8 b2 b2 bc 34 28 94 fe ba 0f 45 |.A.#.....4(....E| 00000030 11 b5 c6 d8 a1 ca c2 ec 08 5e 48 d4 7f 17 a8 75 |.........^H....u| 00000040 af ef ef f1 7a 0f 2f bf 64 c2 3a 9c |....z./.d.:.| 0000004c 0 2 76 So what was once 79 bytes has been reduced to 76 by means of the $() or backtick operator. Not a problem for the crypto utilities per se, but I wanted to point out that you are effectively only having a 76-long key here. The chance to get a key shorter than the requested 79 is 27%. ># avoid newline here >echo -n $KEY | openssl aes-256-cbc > /etc/security/super.key > ># format it, using "--keyfile=-" as mentioned in bugs ... >openssl aes-256-cbc -d -in /etc/security/super.key | cryptsetup -v >--key-file=- --cipher aes-cbc-plain --key-size 256 luksFormat >/dev/VG01/sgwcrypt > ># open it >openssl aes-256-cbc -d -in /etc/security/super.key | cryptsetup -v >--key-file=- luksOpen /dev/VG01/sgwcrypt newhome Turns out cryptsetup has yet another oddity. With LUKS, --key-file=- is moot. Instead.... [fkey is the unencrypted one] # cryptsetup luksFormat /dev/loop94 t-crypt.fkey && \ cryptsetup --key-file=- luksOpen /dev/loop94 x94 <t-crypt.fkey Key slot 0 unlocked. And you thought that doc/bugs.txt described all cryptsetup CLI oddities. *facepalm* ANYWAY. If I proceed with this luks container now, all succeeds: # mkfs.ext4 /dev/mapper/x94 mke2fs 1.41.9 (22-Aug-2009) ... # cryptsetup remove x94 First, let's see if raw passthrough works: # ./mount.crypt -vo keyfile=t-crypt.fkey,fsk_cipher=none /dev/loop94 /mnt command: 'readlink' '-fn' '/dev/loop94' command: 'readlink' '-fn' '/mnt' mount.crypt(crypto-dmc.c:144): Using _dev_loop94 as dmdevice name command: 'mount' '-n' '/dev/mapper/_dev_loop94' '/mnt' # df /mnt Filesystem 1K-blocks Used Available Use% Mounted on /dev/loop94 62465 5365 53875 10% /mnt # PMT_DEBUG_UMOUNT=1 ./umount.crypt /mnt Now the openssl-encrypted file: # ./mount.crypt -vo keyfile=t-crypt.key,fsk_cipher=aes-256-cbc,fsk_hash=md5 /dev/loop94 /mnt command: 'readlink' '-fn' '/dev/loop94' command: 'readlink' '-fn' '/mnt' Password: mount.crypt(crypto-dmc.c:144): Using _dev_loop94 as dmdevice name command: 'mount' '-n' '/dev/mapper/_dev_loop94' '/mnt' # df /mnt Filesystem 1K-blocks Used Available Use% Mounted on /dev/loop94 62465 5365 53875 10% /mnt Match?