Re: [gentoo-user] Re: Kernel upgrade and now LUKS failure

[Jan Engelhardt <jengelh@medozas.de>]

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?