Re: [dm-crypt] The future of disk encryption with LUKS2

[Arno Wagner <arno@wagner.name>]

On Sat, Feb 06, 2016 at 11:01:40 CET, Michael Kjörling wrote:
> On 6 Feb 2016 04:18 +0100, from sven@whgl.uni-frankfurt.de (Sven Eschenberg):
> > (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).
> 
> 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 
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.
 
But you do need the update to all headers or the key-management 
becomes broken. A simple example is that a key has been 
compromised and you change it. Unless this removes the old one 
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 
way to fix that.

Regards,
Arno


-- 
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 
"news" is "something that hardly ever happens." -- Bruce Schneier