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

[Arno Wagner <arno@wagner.name>]

I think you are asking for a lot more "magic" than is safe
here. If you are a mrer "user", you have no business resizing
a LUKS container in the first place. You need to know what you
are doing to do so safely.

Arno

On Thu, Feb 04, 2016 at 19:42:43 CET, Michael Kjörling wrote:
> On 4 Feb 2016 18:23 +0100, from arno@wagner.name (Arno Wagner):
> > if you place a copy of the header at the end,
> 
> It doesn't need to be at the end of the container either; that's just
> a convenient spot, particularly because the size of the device backing
> the container is already known and it's far away from the beginning of
> the container. The most important aspect would likely be that the two
> locations are unlikely to be affected by any single error, which is
> trivial to show to be the case on HDDs with far-removed LBA addresses,
> and is easy to argue is highly likely on SSDs in the same case.
> 
> > you already
> > need some way to know where the end is and to reserve space
> > at it. A resize could then be as simple as an additional
> > "luksUpdateHeaderCopy" afterwards (whith all other 
> > header-changing operations doing that implicitely already).
> 
> I don't know anything about what hooks are available or practical, but
> an alternative might be to hook into the "resize" control flow and
> move the header through there. That would be a much cleaner approach
> from a user point of view.
> 
> As a user, I would want a usable encrypted container; I don't really
> care where on the disk the metadata to implement this is stored, and I
> certainly wouldn't want the documentation to say "oh, and after you
> run this, you MUST run this other command" just to keep the container
> in a consistent state. That would feel very amateurish. It would be a
> bit like if I store a file on a RAID 1, I then have to resilver the
> array to make sure that the file is on all constituent devices.
> 
> 
> > For completeness and security (preventing an old copy
> > of the header from lingering), a "luksNukeHeaderCopy"
> > would also be required.
> 
> This should be handled transparently by luksErase and/or resize, for
> the same reason cited above; all commands that use or affect the LUKS
> header should strive to keep the container in a consistent state,
> including ensuring that both copies of the metadata are synchronized.
> 
> If absolutely necessary, a command-line switch could be added to
> disable that behavior, with clear warnings about the potential
> implications.
> 
> -- 
> Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
>                  “People who think they know everything really annoy
>                  those of us who know we don’t.” (Bjarne Stroustrup)
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

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