From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Vj2LH-0000z4-PH for mharc-grub-devel@gnu.org; Wed, 20 Nov 2013 02:36:55 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34658) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vj2LA-0000xu-Rt for grub-devel@gnu.org; Wed, 20 Nov 2013 02:36:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vj2L5-0004Wo-Ur for grub-devel@gnu.org; Wed, 20 Nov 2013 02:36:48 -0500 Received: from mail-ea0-x22c.google.com ([2a00:1450:4013:c01::22c]:53582) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vj2L5-0004Wk-O6 for grub-devel@gnu.org; Wed, 20 Nov 2013 02:36:43 -0500 Received: by mail-ea0-f172.google.com with SMTP id q10so1424768ead.3 for ; Tue, 19 Nov 2013 23:36:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=32LKa/hpZXJStNjbI6cnnescHGLwojIer2XmparLPcE=; b=vPf3By4ZE3LeZOQ2fpbSe9AKULQYEyb7z3N92m/+sMikMkRbSVdmy0qnXpTlOAbS/L PN9qypMOryAmF/NrItV9YSjHLmSjsMDzaWRS/vFtJIl4HQRt5wpRxgwgfPt3TYvfEGdi 0joLVaYwMfvOzmzTLzmkHq4JywA2oC+7XmUEONtH9dypSUQ0UFzPAxjKuBdWTHo1CvQi 7mapCZVnMtd2r5VAnThFAkpMxnT3Ry/AnBLJg4bcHVQnkPS3lI50P8iPmZLUdcnHwA9+ 0V4qiRTWxIikDTKqjiYL8BstG6ER4L7jBmoDtQRRwWetMqlWr2P9pn5l+nAKbAwJsyVY 85EQ== X-Received: by 10.15.41.3 with SMTP id r3mr51216eev.74.1384933002839; Tue, 19 Nov 2013 23:36:42 -0800 (PST) Received: from [192.168.1.16] (31-249.1-85.cust.bluewin.ch. [85.1.249.31]) by mx.google.com with ESMTPSA id a6sm56360906eei.10.2013.11.19.23.36.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Nov 2013 23:36:42 -0800 (PST) Message-ID: <528C6688.5010806@gmail.com> Date: Wed, 20 Nov 2013 08:36:40 +0100 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131005 Icedove/17.0.9 MIME-Version: 1.0 To: grub-devel@gnu.org Subject: Re: Keyfile Support for GRUBs LUKS References: <528BF7A9.8010702@ramses-pyramidenbau.de> <20131119193135.7b3b5d2f@crass-Ideapad-Z570> <20131120015540.GA35248@scollay.m5p.com> <20131119234312.3e95e55e@crass-Ideapad-Z570> <528C4D38.7050607@gmail.com> <20131120010244.24adbfa1@crass-Ideapad-Z570> In-Reply-To: <20131120010244.24adbfa1@crass-Ideapad-Z570> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2AXBQASOLFBFMQPQHUFWH" X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c01::22c X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 07:36:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2AXBQASOLFBFMQPQHUFWH Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 20.11.2013 08:02, Glenn Washburn wrote: > On Wed, 20 Nov 2013 06:48:40 +0100 > Vladimir '=CF=86-coder/phcoder' Serbinenko wrote: >=20 >> On 20.11.2013 06:43, Glenn Washburn wrote: >>> Modifying the cipher text just >>> manifests as random data corruption of the plain text device, again >>> not a security issue and nothing that signatures would prevent. >> It's a security threat. Imagine you have somewhere a routine which >> verifies SSH-key when connecting by network. Replace it with random >> data. With some significant probability this decodes to valid opcodes >> but which do no check. Now everyone can use your SSH. >> encryption provides secrecy. Signatures provide verification. Using >> one to achieve the other will always fail. >> >=20 > Let me see if I understand you. Suppose an attacker can modify the LUK= S > containers cipher text and happens to know the exact block which > contains the routine for verifying the ssh key. This is determenistic. > The attacker then > writes some data to that block, which will then manifest as random > bytes once unencrypted. >=20 > You're claiming that there's a more than insignificant probability that= > this could cause the verification to not happen? And thus for anyone > to be able to log into the system via ssh? I hope you're not > suggesting that because it would be ludicrously improbable (try > executing data from /dev/random and see how far you get). It's not as low as you claim. You change only 16 bytes. And you don't need the resulting code to be doing anything useful, just not crash. In CBC modes this attack is even somewhat easier. Read http://www.cs.berkeley.edu/~daw/teaching/cs261-f12/misc/if.html > Also, if this kind of threat were worth considering, why doesn't LUKS > address this? It would seem fairly easy (add some HMACs in the blocks)= =2E It's not that easy. Trouble is that you need to also prevent inconsistent rollback and for this you need to have a hash tree. Then since power failure is a possibility you need this tree to be consistent at every moment. Those issues are a bit easier to handle on FS level. ZFS supports HMACs. BtrFS perhaps will one day. ------enig2AXBQASOLFBFMQPQHUFWH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iF4EAREKAAYFAlKMZogACgkQmBXlbbo5nOuTyAD+Pm6K+tNGBxngPasJIbRyuT+l u4HWZd6DPcIt1agq0ZsBAK3urpj57BT9Pzy8I7kXEYRswvjwibMLvEsDuivPfLuB =+C5e -----END PGP SIGNATURE----- ------enig2AXBQASOLFBFMQPQHUFWH--