Gentoo Archives: gentoo-user

From: "Stefan G. Weichinger" <lists@×××××.at>
To: Jan Engelhardt <jengelh@×××××××.de>
Cc: gentoo-user@l.g.o, Daniel Troeder <daniel@×××××××××.com>, walt <w41ter@×××××.com>, Florian Philipp <lists@××××××××××××××××××.net>, Jason Dusek <jason.dusek@×××××.com>, Till Maas <opensource@××××.name>, hanno@g.o
Subject: Re: [gentoo-user] Re: Kernel upgrade and now LUKS failure
Date: Tue, 18 May 2010 21:50:26
Message-Id: 4BF30B74.9090807@xunil.at
In Reply to: Re: [gentoo-user] Re: Kernel upgrade and now LUKS failure by Jan Engelhardt
1 Am 18.05.2010 23:16, schrieb Jan Engelhardt:
2 > yOn Tuesday 2010-05-18 22:17, Stefan G. Weichinger wrote:
3 >>
4 >> I saved my history, unfortunately only the last steps were kept,
5 >> but I am able to reconstruct:
6 >>
7 >> The block-device is /dev/VG01/sgwcrypt ...
8 >>
9 >> #I tried a more complicated KEY KEY=`head -c 79 /dev/urandom`
10 >
11 > Well, I'm not going to blame you yet, but the shell is pretty
12 > binary-unsafe -- and you have just invoked that voodoo again.
13 >
14 > # head -c79 /dev/urandom >t-crypt.ukey; \ hexdump -C <t-crypt.ukey;
15 > \ KEY=$(cat t-crypt.ukey); \ echo -n "$KEY" | hexdump -C; \ echo -n
16 > "$KEY" | wc; 00000000 a4 b2 c8 a0 4f c9 00 37 66 f3 0c 20 2d 5c 05
17 > e7 |....O..7f.. -\..| 00000010 cd 5e 5d 00 5d e1 18 2a 1a 8b 2d 41
18 > 22 e7 66 0e |.^].]..*..-A".f.| 00000020 b0 a3 1d 41 1e 23 1d 00 f8
19 > b2 b2 bc 34 28 94 fe |...A.#......4(..| 00000030 ba 0f 45 11 b5 c6
20 > d8 a1 ca c2 ec 08 5e 48 d4 7f |..E.........^H..| 00000040 17 a8 75
21 > af ef ef f1 7a 0f 2f bf 64 c2 3a 9c |..u....z./.d.:.| 0000004f
22 >
23 > 00000000 a4 b2 c8 a0 4f c9 37 66 f3 0c 20 2d 5c 05 e7 cd
24 > |....O.7f.. -\...| 00000010 5e 5d 5d e1 18 2a 1a 8b 2d 41 22 e7 66
25 > 0e b0 a3 |^]]..*..-A".f...| 00000020 1d 41 1e 23 1d f8 b2 b2 bc 34
26 > 28 94 fe ba 0f 45 |.A.#.....4(....E| 00000030 11 b5 c6 d8 a1 ca c2
27 > ec 08 5e 48 d4 7f 17 a8 75 |.........^H....u| 00000040 af ef ef f1
28 > 7a 0f 2f bf 64 c2 3a 9c |....z./.d.:.| 0000004c 0
29 > 2 76
30 >
31 > So what was once 79 bytes has been reduced to 76 by means of the $()
32 > or backtick operator.
33 >
34 > Not a problem for the crypto utilities per se, but I wanted to point
35 > out that you are effectively only having a 76-long key here. The
36 > chance to get a key shorter than the requested 79 is 27%.
37 >
38 >> # avoid newline here echo -n $KEY | openssl aes-256-cbc >
39 >> /etc/security/super.key
40 >>
41 >> # format it, using "--keyfile=-" as mentioned in bugs ... openssl
42 >> aes-256-cbc -d -in /etc/security/super.key | cryptsetup -v
43 >> --key-file=- --cipher aes-cbc-plain --key-size 256 luksFormat
44 >> /dev/VG01/sgwcrypt
45 >>
46 >> # open it openssl aes-256-cbc -d -in /etc/security/super.key |
47 >> cryptsetup -v --key-file=- luksOpen /dev/VG01/sgwcrypt newhome
48 >
49 > Turns out cryptsetup has yet another oddity. With LUKS, --key-file=-
50 > is moot. Instead....
51 >
52 > [fkey is the unencrypted one]
53 >
54 > # cryptsetup luksFormat /dev/loop94 t-crypt.fkey && \ cryptsetup
55 > --key-file=- luksOpen /dev/loop94 x94 <t-crypt.fkey Key slot 0
56 > unlocked.
57 >
58 >
59 > And you thought that doc/bugs.txt described all cryptsetup CLI
60 > oddities.
61 >
62 > *facepalm*
63 >
64 > ANYWAY.
65 >
66 >
67 > If I proceed with this luks container now, all succeeds:
68 >
69 > # mkfs.ext4 /dev/mapper/x94 mke2fs 1.41.9 (22-Aug-2009) ... #
70 > cryptsetup remove x94
71 >
72 > First, let's see if raw passthrough works:
73 >
74 > # ./mount.crypt -vo keyfile=t-crypt.fkey,fsk_cipher=none /dev/loop94
75 > /mnt command: 'readlink' '-fn' '/dev/loop94' command: 'readlink'
76 > '-fn' '/mnt' mount.crypt(crypto-dmc.c:144): Using _dev_loop94 as
77 > dmdevice name command: 'mount' '-n' '/dev/mapper/_dev_loop94' '/mnt'
78 > # df /mnt Filesystem 1K-blocks Used Available Use%
79 > Mounted on /dev/loop94 62465 5365 53875 10%
80 > /mnt # PMT_DEBUG_UMOUNT=1 ./umount.crypt /mnt
81 >
82 >
83 > Now the openssl-encrypted file:
84 >
85 > # ./mount.crypt -vo
86 > keyfile=t-crypt.key,fsk_cipher=aes-256-cbc,fsk_hash=md5 /dev/loop94
87 > /mnt command: 'readlink' '-fn' '/dev/loop94' command: 'readlink'
88 > '-fn' '/mnt' Password: mount.crypt(crypto-dmc.c:144): Using
89 > _dev_loop94 as dmdevice name command: 'mount' '-n'
90 > '/dev/mapper/_dev_loop94' '/mnt' # df /mnt Filesystem
91 > 1K-blocks Used Available Use% Mounted on /dev/loop94
92 > 62465 5365 53875 10% /mnt
93 >
94 >
95 > Match?
96
97 Frankly: dunno ;-)
98 Yes, I am able to follow and understand in general so far ... but ...
99
100 Assuming that "I am too stupid": Where is the how-to-do-it?
101
102 So far the only thing I really understood "You are doing it wrong".
103
104 But where is the "Do it this way and you are safe" ?
105
106 I wouldn't post here if I were competent enough to know all these details.
107
108 Concerning encryption I am at the USER-level, you know for sure ;-)
109
110 Just trying to feed back my problems to maybe detect bugs or my mistakes.
111
112 Stefan

Replies

Subject Author
Re: [gentoo-user] Re: Kernel upgrade and now LUKS failure Jan Engelhardt <jengelh@×××××××.de>