From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smail.rz.tu-ilmenau.de (smail.rz.tu-ilmenau.de [141.24.4.149]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Sun, 7 Feb 2016 01:13:32 +0100 (CET) Received: from [141.24.172.217] (unknown [141.24.172.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smail.rz.tu-ilmenau.de (Postfix) with ESMTPSA id 6CBB15EF62 for ; Sun, 7 Feb 2016 02:09:34 +0100 (CET) References: <20160204092017.GA25029@yeono.kjorling.se> <56B37D92.2030306@whgl.uni-frankfurt.de> <20160204172311.GB20874@tansi.org> <20160205155743.GA32705@tansi.org> <56B5356B.3030704@whgl.uni-frankfurt.de> <20160206025854.GA5986@tansi.org> <56B56605.4030907@whgl.uni-frankfurt.de> <20160206100140.GU13740@yeono.kjorling.se> <56B641C2.4070400@whgl.uni-frankfurt.de> <20160206190916.GA20801@yeono.kjorling.se> <56B646EA.1050100@whgl.uni-frankfurt.de> From: Lars Winterfeld Message-ID: <56B68B4A.4000906@tu-ilmenau.de> Date: Sun, 7 Feb 2016 01:09:46 +0100 MIME-Version: 1.0 In-Reply-To: <56B646EA.1050100@whgl.uni-frankfurt.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="p2wHiNr4u9NHwi7oGjJLO2fXbR3IVNrvU" Subject: Re: [dm-crypt] The future of disk encryption with LUKS2 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --p2wHiNr4u9NHwi7oGjJLO2fXbR3IVNrvU Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 06.02.2016 20:18, Sven Eschenberg wrote: > Okay, I see, for simple updates a counter could indeed be sufficient to= > ensure consistency by bringing the header with lower counter in sync > with the other one. If one is afraid of, e.g., power loss in the middle of rewriting the header, there could also be a "changing header" flag that is set to 1 first, then header data is changed, then the flag is reset to 0. If you later find a flag set to 1, you should restore the other "backup" header. Maybe this is useful in very rare cases, but also very easy to implement, so one could still do it? --p2wHiNr4u9NHwi7oGjJLO2fXbR3IVNrvU 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 iQIcBAEBCAAGBQJWtotKAAoJEHVR+BAIQ6ateesP/04DGraVj87/f50pv9w4nZ6s a7QKlO6arxFycJCJpIbvxslAgBb2ub7Gq5flMGN/9Qi1CJADKFi8KHBySaHw65Ep W0/DFmGNJI2QaCp9/MusCkWVM+HP4mIWFTW2DDyYP9EAB5AjJaU1ebjPTAwaMvu+ 6/Uqcueuj0xKA0k58YIbLnyb4kRiZrgs/W6MG+RoITzYJHxCwD0qqs6E0EjMfHAo X35MX6CqrqpS28Y5EqPzzKV5HGPGY6qyrwzfcDCRmC68OVrHHIyYFT2E1TzbtEQ2 oZE6P365FusDYrROg1MW6NZLb7mRlqKSX0ypd2JvDzaVuo00K4SKFW8sHnRl+EtU hUJQoMlqTjzRfoTEbjWwHa552fOl5L4uCclKteoA2yN+waLnTZi5SbElCw+1MmSj z961GUnmozLpEVhZwlxHJubR3xwaHj2QBIq4XtsCw9SROmm9gylG1DqsZr2KqS44 d8IKuNVHbRbD/A3mpICvWo+nlF24M5L3NQCqbCpoHcLnUcB/sD2JFLtonSdx39Gg Xb/rydP9pG4MGxkVOjPytRI6Bcp6TBxMP5NAUA3bdGQghZkYBYoTrBbeaKSSpdN8 wQBZcUNTwqxtF8V+vvK4G0H7H0v0udhy5w3Yd+T43udVmit8X8wBNfvBiCevtKSN WtJJPVI54kmWtggYXdh/ =3OzR -----END PGP SIGNATURE----- --p2wHiNr4u9NHwi7oGjJLO2fXbR3IVNrvU--