1 |
On 05/17/2010 11:14 AM, Stefan G. Weichinger wrote: |
2 |
> Am 16.05.2010 14:36, schrieb Jan Engelhardt: |
3 |
>> [Replying to |
4 |
>> http://thread.gmane.org/gmane.linux.gentoo.user/229533/focus=229542 |
5 |
>> ] |
6 |
>> |
7 |
>> In my personal opinion, both the quality of shell commands and key |
8 |
>> generation is suboptimal. What makes it bad is that people follow |
9 |
>> it. |
10 |
>> |
11 |
>> First, it generates a key which does not exploit the entire space. |
12 |
>> People claim it's because they want an ASCII readout, but frankly, |
13 |
>> you get the same with `hexdump -C`. |
14 |
>> |
15 |
>> Second, it's using echo without the -n parameter, thus implicitly |
16 |
>> inserting a newline into the key -- which is the cause for yoru |
17 |
>> observed mounting problems. |
18 |
>> |
19 |
>> Third, because you are passing the key via stdin into cryptsetup, it |
20 |
>> only uses the first line of whatever you pipe into it; whereas |
21 |
>> pam_mount uses the entire keyfile as it is supposed to be. |
22 |
>> |
23 |
>> (Fourth, the howto suggests ECB, which, well, looks rather weak |
24 |
>> considering the ECB's Tux picture on Wikipedia.) |
25 |
>> |
26 |
>> All of that should be in doc/bugs.txt, and mount.crypt even warns |
27 |
>> about ECB. You really cannot ignore seeing that. |
28 |
>> |
29 |
>> Phew! |
30 |
> |
31 |
> Jan, thanks for your suggestions. |
32 |
> |
33 |
> I created a new LUKS-volume and tried to avoid all the mentioned |
34 |
> pitfalls (I used "echo -n", avoided stdin etc.), but this didn't help here. |
35 |
> |
36 |
> The new volume is not mounted with pam_mount-2.1, but mounted OK with |
37 |
> pam_mount-1.33. |
38 |
> |
39 |
> And, btw, as mentioned in the original thread, I use CBC, not ECB ;-) |
40 |
> |
41 |
> -- Your CCing Daniel didn't work maybe, wrong address, I corrected it |
42 |
> for this reply) |
43 |
> |
44 |
> -- I CC: hanno@g.o to link to the gentoo bug |
45 |
> |
46 |
> http://bugs.gentoo.org/show_bug.cgi?id=318865 |
47 |
> |
48 |
> Thanks, regards, Stefan |
49 |
> |
50 |
Hello :) |
51 |
|
52 |
In a more general discussion I wonder what the advantage of using a SSL |
53 |
encrypted key for HDD-encryption is. |
54 |
|
55 |
As the SSL-keyfile is as well protected as the password to decrypt it is |
56 |
"difficult", so would be a directly encrypted HDD with the same password |
57 |
- or not? |
58 |
|
59 |
If this assumption is correct, then I think the direct approach would be |
60 |
better, as in "less complexity - less errors". |
61 |
|
62 |
<For the paranoid> |
63 |
I think it is much easier to hide a trojan/keylogger on an unencrypted |
64 |
root-partition than in an initramfs - and not be detected. (Both is easy |
65 |
to do, but the latter can be detected easier.) Unfortunately that |
66 |
detection is never done... after opening the root-dev some form of |
67 |
file-/partition-manipulation check should run. Though the kernel could |
68 |
be already compromised... Only a secure boot-path like with TCG is |
69 |
really secure... well this is only if you fear strong attackers, and not |
70 |
only loosing your notebook :) I head that really strong attackers would |
71 |
hide a keylogger beneath your keyboard... but if you have that kind of |
72 |
opponent, then you really have other problems too :) |
73 |
</For the paranoid> |
74 |
|
75 |
Anyway - if your /tmp is not encrypted you should put it on a ram-disk: |
76 |
gives you speed and privacy in case of robbery. Also important is to |
77 |
have the screensaver lock the screen. |
78 |
|
79 |
On a technical note: I use "xts" as I read it's a good (although new) algo. |
80 |
|
81 |
Bye, |
82 |
Daniel |
83 |
|
84 |
|
85 |
BTW: No need to CC mailing list mails to me - I'll read and reply the |
86 |
ML-thread when I have time :) |
87 |
|
88 |
|
89 |
-- |
90 |
PGP key @ http://pgpkeys.pca.dfn.de/pks/lookup?search=0xBB9D4887&op=get |
91 |
# gpg --recv-keys --keyserver hkp://subkeys.pgp.net 0xBB9D4887 |