From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1OE7Rt-0003Uj-91 for garchives@archives.gentoo.org; Mon, 17 May 2010 21:02:05 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C5277E0743; Mon, 17 May 2010 21:01:08 +0000 (UTC) Received: from mx01.admin-box.com (mx01.admin-box.com [78.47.249.108]) by pigeon.gentoo.org (Postfix) with ESMTP id 7E985E0743 for ; Mon, 17 May 2010 21:01:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mx01.admin-box.com (Postfix) with ESMTP id B66D131F0315 for ; Mon, 17 May 2010 23:01:06 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mx01.admin-box.com Received: from mx01.admin-box.com ([127.0.0.1]) by localhost (mx01.admin-box.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id McXTkKHiaTej for ; Mon, 17 May 2010 23:01:01 +0200 (CEST) Received: from maya.local (e178060213.adsl.alicedsl.de [85.178.60.213]) (Authenticated sender: daniel@troeder.de) by mx01.admin-box.com (Postfix) with ESMTPSA id 73D2A31F0306 for ; Mon, 17 May 2010 23:01:01 +0200 (CEST) Message-ID: <4BF1AE8D.6060001@admin-box.com> Date: Mon, 17 May 2010 23:01:01 +0200 From: Daniel Troeder User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100511 Thunderbird/3.0.4 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: Kernel upgrade and now LUKS failure References: <4BF108F3.1080304@xunil.at> In-Reply-To: <4BF108F3.1080304@xunil.at> X-Enigmail-Version: 1.0.1 OpenPGP: id=BB9D4887; url=http://pgpkeys.pca.dfn.de/pks/lookup?search=0xBB9D4887&op=get Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig12158CC1DBC376264AEB8823" X-Archives-Salt: 353c7ca3-dfd4-4243-a26f-cf5e5212b262 X-Archives-Hash: 0a849e8e8fba0d05d2d2470c0f23c4bf This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig12158CC1DBC376264AEB8823 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 05/17/2010 11:14 AM, Stefan G. Weichinger wrote: > Am 16.05.2010 14:36, schrieb Jan Engelhardt: >> [Replying to=20 >> http://thread.gmane.org/gmane.linux.gentoo.user/229533/focus=3D229542 = >> ] >> >> In my personal opinion, both the quality of shell commands and key=20 >> generation is suboptimal. What makes it bad is that people follow=20 >> it. >> >> First, it generates a key which does not exploit the entire space.=20 >> People claim it's because they want an ASCII readout, but frankly,=20 >> you get the same with `hexdump -C`. >> >> Second, it's using echo without the -n parameter, thus implicitly=20 >> inserting a newline into the key -- which is the cause for yoru=20 >> observed mounting problems. >> >> 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=20 >> pam_mount uses the entire keyfile as it is supposed to be. >> >> (Fourth, the howto suggests ECB, which, well, looks rather weak=20 >> considering the ECB's Tux picture on Wikipedia.) >> >> All of that should be in doc/bugs.txt, and mount.crypt even warns=20 >> about ECB. You really cannot ignore seeing that. >> >> Phew! >=20 > Jan, thanks for your suggestions. >=20 > 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 h= ere. >=20 > The new volume is not mounted with pam_mount-2.1, but mounted OK with > pam_mount-1.33. >=20 > And, btw, as mentioned in the original thread, I use CBC, not ECB ;-) >=20 > -- Your CCing Daniel didn't work maybe, wrong address, I corrected it > for this reply) >=20 > -- I CC: hanno@gentoo.org to link to the gentoo bug >=20 > http://bugs.gentoo.org/show_bug.cgi?id=3D318865 >=20 > Thanks, regards, Stefan >=20 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". 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 :) 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) alg= o. Bye, Daniel BTW: No need to CC mailing list mails to me - I'll read and reply the ML-thread when I have time :) --=20 PGP key @ http://pgpkeys.pca.dfn.de/pks/lookup?search=3D0xBB9D4887&op=3Dg= et # gpg --recv-keys --keyserver hkp://subkeys.pgp.net 0xBB9D4887 --------------enig12158CC1DBC376264AEB8823 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvxro0ACgkQg3+4tbudSIepEQCgoi5qgyY6fOAbs8r/KOkVWCsK 2eMAnRFcijuzd3vv+jfE7X7SzDRNTY6N =zXLA -----END PGP SIGNATURE----- --------------enig12158CC1DBC376264AEB8823--