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 |