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

[Milan Broz <gmazyland@gmail.com>]

On 02/04/2016 10:20 AM, Michael Kjörling wrote:
> On 4 Feb 2016 09:38 +0100, from gmazyland@gmail.com (Milan Broz):
>> On 02/03/2016 08:46 PM, Sven Eschenberg wrote:

> Storing the LUKS header in two separate locations on disk could
> probably do the trick. For example, right at the start *and* right at
> the end of the LUKS container, which would avoid any issues with
> having to remap a location in the middle of the container. Put a
> counter in the header, ensure that all copies are in sync when the
> header is read or written to, and if they are out of sync, use the one
> with the highest counter value that works and rewrite the other. Add a
> checksum (could be something really simple even, like CRC32, but it
> would be good to make this extensible without needing to change the
> on-disk format) to protect against any corruption that somehow manages
> to slip past the FEC in the storage layer.

That is really for design documentation I would like to write and send here,
but that's almost exactly I already have in LUKS2 branch

- two headers with checksum (configurable algorithm, for now just plain sha256)
  (there is different salt for headers and small binary header to be parsed by blkid)

- counter (epoch) and automatic recovery (in fact trivial journal)
 (this does not apply for raw slot key material)

FEC is not needed for header resilience, above works pretty well and it is simple.

The most "fancy" feature is that metadata are in JSON, so I can work even
with "unknown" future type keyslots/segments types and keep its metadata intact.

 
> In fact, that would be similar to how ZFS and Btrfs already solves
> pretty much the same problem.

If you mention these, I would like to have integrity protection (either authenticated
mode or additional integrity data) on block layer encryption level.

And LUKS2 header will allow to add this in future without on-disk header change,
just by defining new segment type.

For now, cryptography algorithms are the same as LUKS1 (except experimental
Argon2 KDF support that need a lot of engineering work for libargon2 library...)
but the format allows upgrade in future without on-disk change.


> I would discourage complex features; in cryptography, simple and easy
> to validate should be the name of the game, and simply storing the
> same data in two distinct locations is _far_ easier to understand than
> code to calculate and use FEC data.

YES, 100% agree with that.

Milan