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

Michael Kjörling michael at kjorling.se
Thu Feb 4 19:42:43 CET 2016

On 4 Feb 2016 18:23 +0100, from arno at 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

Michael Kjörling • https://michael.kjorling.semichael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

More information about the dm-crypt mailing list