From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from v6.tansi.org (mail.tansi.org [87.118.116.4]) by mail.server123.net (Postfix) with ESMTP for ; Sat, 6 Feb 2016 15:29:04 +0100 (CET) Received: from gatewagner.dyndns.org (77-57-36-72.dclient.hispeed.ch [77.57.36.72]) by v6.tansi.org (Postfix) with ESMTPA id 497B420DC211 for ; Sat, 6 Feb 2016 15:29:04 +0100 (CET) Date: Sat, 6 Feb 2016 15:29:03 +0100 From: Arno Wagner Message-ID: <20160206142903.GC11332@tansi.org> References: <56B30DE8.1060502@gmail.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20160206100140.GU13740@yeono.kjorling.se> 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 On Sat, Feb 06, 2016 at 11:01:40 CET, Michael Kj=F6rling wrote: > On 6 Feb 2016 04:18 +0100, from sven@whgl.uni-frankfurt.de (Sven Eschenbe= rg): > > (A secondary header implies that > > all changes on both headers need to be atomic and in sync. While > > this is doable, LVM clearly shows, that it is not trivial, otherwise > > it would certainly be available as feature by now). >=20 > I'm not so sure it does imply that. It does certainly imply the need > to know that a, and which one out of the lot, header is most up to > date, but that does not necessarily require writes to both to be done > atomically and in sync. (In fact, truly atomic, in-sync writes to > multiple distinct locations seems a physical impossibility at least in > the case of a single spinning disk, since the write head can only be > in one location at any one time.) You do not need it atomic on low level. Some soft real-time=20 way to do it is quite enough (with a big error if it fails) as there should not be any competing cryptsetup invocations changing the header. If there are, you are doing it wrong. =20 But you do need the update to all headers or the key-management=20 becomes broken. A simple example is that a key has been=20 compromised and you change it. Unless this removes the old one=20 from all headers, your container becomes insecure. Incidentally, the same applies to a header backup or an image backup including the header. I do warn of this in the FAQ. Here you also need some (usually manual) soft real-time=20 way to fix that. Regards, Arno --=20 Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- A good decision is based on knowledge and not on numbers. -- Plato If it's in the news, don't worry about it. The very definition of=20 "news" is "something that hardly ever happens." -- Bruce Schneier