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

Michael Kjörling michael at kjorling.se
Wed Mar 8 21:53:16 CET 2017


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.

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.

-- 
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