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

Arno Wagner arno at wagner.name
Thu Feb 4 18:23:11 CET 2016

Hi Sven,

if you place a copy of the header at the end, 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).

For completeness and security (preventing an old copy
of the header from lingering), a "luksNukeHeaderCopy"
would also be required.

On the other hand, resizing a Luks container with a 
filesystem in there without killing that filesystem is
already complicated enough that I usually just recomend 
a backup and recreation instead of a resize.


On Thu, Feb 04, 2016 at 17:34:26 CET, Sven Eschenberg wrote:
> Hi all,
> Yes data duplication (a secondary shadow copy of the header)
> together with checksumming for integrity checking is of course
> easier and more straight forward. I thought about FEC (not
> necessarily Reeed-S.) as an alternative that covers both issues
> without introducing an extra location of header data. Then again, if
> the (primary) header is overwritten completely, FECs won't help you
> that much.
> The problem with an extra header at the end of the device is, that
> it makes growing/shrinking a more difficult task. Currently the
> mapping always covers the whole size of the backing device.
> Regards
> -Sven
> Am 04.02.2016 um 10:20 schrieb Michael Kjörling:
> >On 4 Feb 2016 09:38 +0100, from gmazyland at gmail.com (Milan Broz):
> >>On 02/03/2016 08:46 PM, Sven Eschenberg wrote:
> >>>Personally I'd love to see FEC extensions in a v2 on-disk-format.
> >>
> >>Anyway, if you have some real use cases for FEC (and specifically some
> >>real-world examples of data corruption it can fix), please share it, I am
> >>very interested to see that. (I know the problem exist and that FEC could
> >>be useful but seems nobody is able provide any hard data...)
> >
> >Plain data duplication seems both easier to implement and likely to
> >allow recovery from the same as well as other classes of errors.
> >Reed-Solomon and similar FEC is useful when a read is marginal, but
> >useless when a read fails completely, which I believe is a far more
> >common failure mode in the layers of storage that we are interested
> >in.
> >
> >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.
> >
> >In fact, that would be similar to how ZFS and Btrfs already solves
> >pretty much the same problem.
> >
> >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.
> >
> _______________________________________________
> dm-crypt mailing list
> dm-crypt at saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno at 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

More information about the dm-crypt mailing list