1 |
yOn Tuesday 2010-05-18 22:17, Stefan G. Weichinger wrote: |
2 |
> |
3 |
>I saved my history, unfortunately only the last steps were kept, but I |
4 |
>am able to reconstruct: |
5 |
> |
6 |
>The block-device is /dev/VG01/sgwcrypt ... |
7 |
> |
8 |
>#I tried a more complicated KEY |
9 |
>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; \ |
15 |
hexdump -C <t-crypt.ukey; \ |
16 |
KEY=$(cat t-crypt.ukey); \ |
17 |
echo -n "$KEY" | hexdump -C; \ |
18 |
echo -n "$KEY" | wc; |
19 |
00000000 a4 b2 c8 a0 4f c9 00 37 66 f3 0c 20 2d 5c 05 e7 |....O..7f.. -\..| |
20 |
00000010 cd 5e 5d 00 5d e1 18 2a 1a 8b 2d 41 22 e7 66 0e |.^].]..*..-A".f.| |
21 |
00000020 b0 a3 1d 41 1e 23 1d 00 f8 b2 b2 bc 34 28 94 fe |...A.#......4(..| |
22 |
00000030 ba 0f 45 11 b5 c6 d8 a1 ca c2 ec 08 5e 48 d4 7f |..E.........^H..| |
23 |
00000040 17 a8 75 af ef ef f1 7a 0f 2f bf 64 c2 3a 9c |..u....z./.d.:.| |
24 |
0000004f |
25 |
|
26 |
00000000 a4 b2 c8 a0 4f c9 37 66 f3 0c 20 2d 5c 05 e7 cd |....O.7f.. -\...| |
27 |
00000010 5e 5d 5d e1 18 2a 1a 8b 2d 41 22 e7 66 0e b0 a3 |^]]..*..-A".f...| |
28 |
00000020 1d 41 1e 23 1d f8 b2 b2 bc 34 28 94 fe ba 0f 45 |.A.#.....4(....E| |
29 |
00000030 11 b5 c6 d8 a1 ca c2 ec 08 5e 48 d4 7f 17 a8 75 |.........^H....u| |
30 |
00000040 af ef ef f1 7a 0f 2f bf 64 c2 3a 9c |....z./.d.:.| |
31 |
0000004c |
32 |
0 2 76 |
33 |
|
34 |
So what was once 79 bytes has been reduced to 76 by means of the $() |
35 |
or backtick operator. |
36 |
|
37 |
Not a problem for the crypto utilities per se, but I wanted to point out |
38 |
that you are effectively only having a 76-long key here. The chance to |
39 |
get a key shorter than the requested 79 is 27%. |
40 |
|
41 |
># avoid newline here |
42 |
>echo -n $KEY | openssl aes-256-cbc > /etc/security/super.key |
43 |
> |
44 |
># format it, using "--keyfile=-" as mentioned in bugs ... |
45 |
>openssl aes-256-cbc -d -in /etc/security/super.key | cryptsetup -v |
46 |
>--key-file=- --cipher aes-cbc-plain --key-size 256 luksFormat |
47 |
>/dev/VG01/sgwcrypt |
48 |
> |
49 |
># open it |
50 |
>openssl aes-256-cbc -d -in /etc/security/super.key | cryptsetup -v |
51 |
>--key-file=- luksOpen /dev/VG01/sgwcrypt newhome |
52 |
|
53 |
Turns out cryptsetup has yet another oddity. With LUKS, --key-file=- is |
54 |
moot. Instead.... |
55 |
|
56 |
[fkey is the unencrypted one] |
57 |
|
58 |
# cryptsetup luksFormat /dev/loop94 t-crypt.fkey && \ |
59 |
cryptsetup --key-file=- luksOpen /dev/loop94 x94 <t-crypt.fkey |
60 |
Key slot 0 unlocked. |
61 |
|
62 |
|
63 |
And you thought that doc/bugs.txt described all cryptsetup CLI oddities. |
64 |
|
65 |
*facepalm* |
66 |
|
67 |
ANYWAY. |
68 |
|
69 |
|
70 |
If I proceed with this luks container now, all succeeds: |
71 |
|
72 |
# mkfs.ext4 /dev/mapper/x94 |
73 |
mke2fs 1.41.9 (22-Aug-2009) |
74 |
... |
75 |
# cryptsetup remove x94 |
76 |
|
77 |
First, let's see if raw passthrough works: |
78 |
|
79 |
# ./mount.crypt -vo keyfile=t-crypt.fkey,fsk_cipher=none /dev/loop94 /mnt |
80 |
command: 'readlink' '-fn' '/dev/loop94' |
81 |
command: 'readlink' '-fn' '/mnt' |
82 |
mount.crypt(crypto-dmc.c:144): Using _dev_loop94 as dmdevice name |
83 |
command: 'mount' '-n' '/dev/mapper/_dev_loop94' '/mnt' |
84 |
# df /mnt |
85 |
Filesystem 1K-blocks Used Available Use% Mounted on |
86 |
/dev/loop94 62465 5365 53875 10% /mnt |
87 |
# PMT_DEBUG_UMOUNT=1 ./umount.crypt /mnt |
88 |
|
89 |
|
90 |
Now the openssl-encrypted file: |
91 |
|
92 |
# ./mount.crypt -vo keyfile=t-crypt.key,fsk_cipher=aes-256-cbc,fsk_hash=md5 /dev/loop94 /mnt |
93 |
command: 'readlink' '-fn' '/dev/loop94' |
94 |
command: 'readlink' '-fn' '/mnt' |
95 |
Password: |
96 |
mount.crypt(crypto-dmc.c:144): Using _dev_loop94 as dmdevice name |
97 |
command: 'mount' '-n' '/dev/mapper/_dev_loop94' '/mnt' |
98 |
# df /mnt |
99 |
Filesystem 1K-blocks Used Available Use% Mounted on |
100 |
/dev/loop94 62465 5365 53875 10% /mnt |
101 |
|
102 |
|
103 |
Match? |