On 8 Mar 2017 20:55 +0100, from daniel@xxxxxxxxxxx: > 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.se • michael@xxxxxxxxxxx “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup) _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
