Re: [dm-crypt] please HELP - can't acces encrypted LVM after linux reinstallation.

[Jonas Meurer <jonas@freesources.org>]

-----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-----