[dm-crypt] Cryptsetup-reencrypt and data integrity.

daniel at borek.me.uk daniel at borek.me.uk
Wed Mar 8 23:57:31 CET 2017

> On March 8, 2017 at 9:53 PM Michael Kjörling <michael at kjorling.se> wrote:
> On 8 Mar 2017 20:55 +0100, from daniel at borek.me.uk:
> > I was playing with cryptsetup-reencrypt recently and I noticed it doesn't do
> > any
> > integrity checks on re-encrypted data and there is an assumption everything
> > went
> > fine once the command completes. Are there any plans to introduce integrity
> > checks in the future? I understanding that verifying large volumes of data
> > would
> > be a time consuming task but lack of such option may be a show stopper for
> > some
> > setups.
> How do you propose such integrity checking should be performed?
> Remember that a LUKS container may be (at least for all practical
> purposes) arbitrarily large. Also, if any inconsistencies are found,
> how should the tool respond? At that point, it's not like it can go
> back and undo (or redo) what was done.
There are many ways in which data can be integrity can be possibly checked,
including checksums, xors of continuous blocks and others, it's certainly doable
on large scale. Also, assuming we have a backup, all we'd need is the tool to
tell us "oops, something went wrong, go and fix it". Per Arno's email, it's hard
to argue data integrity is a huge concern to you if you don't have backups.

> If this is a showstopper issue for you, there is always the option of
> creating a new container and copying the data from one mapped device
> to another. (cat /dev/mapper/source > /dev/mapper/target, or more
> likely the same with something like ddrescue.) You can then check the
> data integrity in any way you like, and handle mismatches in any way
> you like.
> Or you can take the approach that storage is potentially unreliable
> for any number of reasons, many of which completely unrelated to LUKS,
> and use something within the container that gives you integrity
> checking and recovery capability. Redundant ZFS or Btrfs are probably
> good candidates there, but other alternatives exist.
Don't get me wrong, I'm not trying to lash out at LUKS for not having features
not advertised in its specs and in fact my question isn't LUKS related at all,
it's about cryptsetup-reencrypt only. There are environments with certain
constraints, where there's no file system support (ie RHEL and zfs) or no file
system exists on disk at all. I was mainly curious whether disk integrity as an
additional functionality is something on the horizon for cryptsetup-reencrypt.

> --
> 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)
> _______________________________________________
> dm-crypt mailing list
> dm-crypt at saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.saout.de/pipermail/dm-crypt/attachments/20170308/114cf50a/attachment.html>

More information about the dm-crypt mailing list