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

[Daniel Troeder <daniel@admin-box.com>]

[-- Attachment #1: Type: text/plain, Size: 3480 bytes --]

On 05/17/2010 11:14 AM, Stefan G. Weichinger wrote:
> Am 16.05.2010 14:36, schrieb Jan Engelhardt:
>> [Replying to 
>> http://thread.gmane.org/gmane.linux.gentoo.user/229533/focus=229542 
>> ]
>>
>> In my personal opinion, both the quality of shell commands and key 
>> generation is suboptimal. What makes it bad is that people follow 
>> it.
>>
>> First, it generates a key which does not exploit the entire space. 
>> People claim it's because they want an ASCII readout, but frankly, 
>> you get the same with `hexdump -C`.
>>
>> Second, it's using echo without the -n parameter, thus implicitly 
>> inserting a newline into the key -- which is the cause for yoru 
>> observed mounting problems.
>>
>> Third, because you are passing the key via stdin into cryptsetup, it 
>> only uses the first line of whatever you pipe into it; whereas 
>> pam_mount uses the entire keyfile as it is supposed to be.
>>
>> (Fourth, the howto suggests ECB, which, well, looks rather weak 
>> considering the ECB's Tux picture on Wikipedia.)
>>
>> All of that should be in doc/bugs.txt, and mount.crypt even warns 
>> about ECB. You really cannot ignore seeing that.
>>
>> Phew!
> 
> Jan, thanks for your suggestions.
> 
> I created a new LUKS-volume and tried to avoid all the mentioned
> pitfalls (I used "echo -n", avoided stdin etc.), but this didn't help here.
> 
> The new volume is not mounted with pam_mount-2.1, but mounted OK with
> pam_mount-1.33.
> 
> And, btw, as mentioned in the original thread, I use CBC, not ECB ;-)
> 
> -- Your CCing Daniel didn't work maybe, wrong address, I corrected it
> for this reply)
> 
> -- I CC: hanno@gentoo.org to link to the gentoo bug
> 
> http://bugs.gentoo.org/show_bug.cgi?id=318865
> 
> Thanks, regards, Stefan
> 
Hello :)

In a more general discussion I wonder what the advantage of using a SSL
encrypted key for HDD-encryption is.

As the SSL-keyfile is as well protected as the password to decrypt it is
"difficult", so would be a directly encrypted HDD with the same password
- or not?

If this assumption is correct, then I think the direct approach would be
better, as in "less complexity - less errors".

<For the paranoid>
I think it is much easier to hide a trojan/keylogger on an unencrypted
root-partition than in an initramfs - and not be detected. (Both is easy
to do, but the latter can be detected easier.) Unfortunately that
detection is never done... after opening the root-dev some form of
file-/partition-manipulation check should run. Though the kernel could
be already compromised... Only a secure boot-path like with TCG is
really secure... well this is only if you fear strong attackers, and not
only loosing your notebook :) I head that really strong attackers would
hide a keylogger beneath your keyboard... but if you have that kind of
opponent, then you really have other problems too :)
</For the paranoid>

Anyway - if your /tmp is not encrypted you should put it on a ram-disk:
gives you speed and privacy in case of robbery. Also important is to
have the screensaver lock the screen.

On a technical note: I use "xts" as I read it's a good (although new) algo.

Bye,
Daniel


BTW: No need to CC mailing list mails to me - I'll read and reply the
ML-thread when I have time :)


-- 
PGP key @ http://pgpkeys.pca.dfn.de/pks/lookup?search=0xBB9D4887&op=get
# gpg --recv-keys --keyserver hkp://subkeys.pgp.net 0xBB9D4887


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]