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

[Milan Broz <gmazyland@gmail.com>]

On 02/10/2016 12:35 AM, Arno Wagner wrote:
> On Tue, Feb 09, 2016 at 23:08:19 CET, Lars Winterfeld wrote:
>> On 08.02.2016 22:51, Milan Broz wrote:
>>> [Just note to already crazy discussion here - there will be NO LUKS header
>>> at the end of device. Been there with another storage project and
>>> just no - it is not worth problems it causes.]
>>
>> Out of curiosity: what were those problems?

I think the real problem was mentioning here several times -
the device size sometimes changes and you have no real control over it.

People resize partition tables, logical volumes, use dd from
smaller disk to bigger (and vice versa but that's another story ;-)

Then you have not always chance to properly wipe out old header, and
in the LUKS case it is additional security risk.

(If you do not wipe additional space it is not so big problem.)

Also note that GPT stores backup header near the end of device,
I can imagine various semi-destroyed headers by that as well.

In case of a "forensic" recovery (you are trying to recover some
partially wiped disk) it complicates thinks even more (should
we expect that a second header somewhere on the device has correct device
size in it or it is just old header and the real one was destroyed?)
(If we have sequence if or epoch in such metadata - what to do
if there is more recent version - because some people tried to recover
with wrong device size (common mistake to try recovery before thinking
of the real problem)? What if it is an older metadata from some
previous install - can we expect always different UUID?)

From the LUKS POV it means that there is no need to change logic
of backup and recovery of header (just replace header, no need to
play magic with writing to device end).

With external scripts (and even programs compiled without proper flags)
you have even bigger chance to screw it up for large devices
when calculating header position because of limited integers handling
(note getsize/getsize64 in blockdev command for example).

The implementation is more complicated but that's not the reason
to reject it (despite I prefer simpler code).

IIRC for lvm2 the resize with redundant metadata (located near the end of PV)
was disabled for some time (code was not complete to handle it)
but today it should work (just FYI).

...
> Was the problem confusion/complexity because this 
> layering-sheme was violated?

That is another problem - during storage stack resize you require user
to do various complicated steps. If a layer just takes current device size
without any complicated steps it effectively limits area for error.
(Well, it can be exact opposite in some situations but I expect people are
more extending devices than shrinking it.)

(In current LUKS2 metadata we can store segment size, so we can limit
device size in header but this is meant for some internal segment handling
like reencryption which requires several segments of sliding window
with limited size. Default is still "use current device size".)

So my reason to not use header near the end of the device is mainly
that security risk of possibly old keyslot material on device.

Milan