From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwybipH3Ve8u for ; Mon, 31 Oct 2011 23:48:16 +0100 (CET) Received: from mail01.freesources.org (mail01.freesources.org [80.237.252.149]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Mon, 31 Oct 2011 23:48:16 +0100 (CET) Received: from ip-94-79-161-2.unitymediagroup.de ([94.79.161.2] helo=[192.168.0.104]) by mail01.freesources.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RL0eM-0005Op-88 for dm-crypt@saout.de; Mon, 31 Oct 2011 22:48:15 +0000 Message-ID: <4EAF25AD.9080200@freesources.org> Date: Mon, 31 Oct 2011 23:48:13 +0100 From: Jonas Meurer MIME-Version: 1.0 References: <20111028172044.GA1850@fancy-poultry.org> <20111029074352.GA6320@tansi.org> <20111030173230.GA31497@tansi.org> <4EADCEF5.2070405@freesources.org> <4EAE1643.9030501@binarysignals.net> <20111031071832.GA9071@tansi.org> <4EAF1E95.1070203@freesources.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] please HELP - can't acces encrypted LVM after linux reinstallation. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 31.10.2011 23:34, schrieb Claudio Moretti: > While I agree with you, that cryptsetup already does a lot to > prevent data (i.e. header) loss, I don't see a reason why > (optional) header backup at some random place on the device would > be such a big security problem. > > Because it would significantly decrease the efficiency of > cryptsetup anti-forensic features, if i'm not wrong.. Meaning that > if the header is stored somewhere in the disk, that place should be > traceable: if it is random, there has to be some known place where > its location is stored; if the location information is not stored, > but one has to analyze the entire disk to find it, analyzing the > disk would expose the header; this applies also to the "fixed > header location" hypothesis. That's what I think I have understood > from previous (similar and related) discussions with Arno; please, > correct me if I'm mistaken. I don't suggest to hide the backup header. In fact the exact place of it should be obvious (either fixed, or better: random but written to the first header). Thus the second header is as obvious as the first one. Only difference: it's not at the beginning of the device. Unfortunately the first sectors of a device are overwritten much more often than later sectors. I see that a backup header - which for sure needs to be overwritten by new luksFormat - wouldn't prevent accidents like the one explained in the first message to this thread. Only in cases where people accidently overwrite the first sectors of a luks device, this kind of backup header could prevent data loss. Greetings, jonas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOryWtAAoJEFJi5/9JEEn+wU0P/jYjfauG4Ak1C+eLZ/YzkSEH Lf5KY5WlIip3dKSkrgtZ9EjIB71PJbDhvdA0QLG6k/5MbubrDqSIGf+rb8LvJ46n FlaBob16VcpWbhdycgk07DRjt94lkI7IZg3LrLcK3f1xD53Ztyo96dqUlAU6jOzB qNjhQawgViTR6YPeMozUs8fn4gPAFp5AzxdmOpvoPCuErk3A8/r7T5NBRtDROPw8 7tva1AQvoFYHh8ZmSCncTN/1h0QGMTjWVY4rVUVypk7p8axbFOUQWqpnKQ15Vee/ XfPavhd8d4ws/z0OOfMn5bLQt4c9UhWC8wbr74rt/TCkXVggx4HAUT4XHZItRkK4 8MxPZLCDxINedy1s5cpkgWFpptmqNbraf9iof2DXjQLQw1V+FABIDYXV1YxzGqc7 eWKPtpNTvhwBVYZ3PsEXIqnLTo2yrzit5/GQsk/MKgGFcJRYfK9/MqVkRWb0YNR+ tmt+H0y1TZXKm265EcryjvJ1jVJ7fylAtSbMGOW8OUHvLHTZfkzF2HZ7uhdy36RB czEHt6WbfpZI783fjp6C3SnPNM3MJXd+UTWJN5uCaWaxWNols1mZI/Jn8M2GUDQH TtwDDSwq/a+R63piVrvjLNJKglbjz/Km6j/Nz/VUY9B07+Ih+dPhNKOB62fl0DTW QL8T/nDXlV4Z/IXq5Q1M =5p2O -----END PGP SIGNATURE-----