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: ha...@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
signature.asc
Description: OpenPGP digital signature
