On 03/01/2018 03:59 PM, Lukáš Pohanka wrote: > thanks for clarifications. Unfortunately, we are currently > constrained to use only dmsetup and cannot provision the target > device with cryptsetup. Thus we cannot use LUKS, only plain > dm-crypt. Hopefully it will change in the future. However, does this > mean there is currently no chance of using any form of authenticated > encryption in our case? Hi, you can use it just with dmsetup, but there are several steps that are not obvious (for example formatting dm-integrity device requires two steps etc). But it is definitely something I would not suggest :-) So in general (I intentionally do not want to paste exact commands, you have to be sure what you are doing here): - you will need recent-enough kernel (4.12+) Formatting (only once): - prepare block device, wipe first megabytes with zeroes - activate dm-integrity device (using dm-setup) with size 8 sectors, and with proper parameters (mainly tag size per sector) you need (do not use internal hash) - deactivate dm-integrity device (Steps above will format the device in-kernel, writing integrity superblock.) Later use (normal activation): - activate dm-integrity device with proper data size (read from dm-integrity superblock). (In future it will be simpler.) - activate dm-crypt device with proper parameters above the dm-itegrity device (with proper authentication mode parameters, tag size, random IV etc) - Profit. (Use top-level dm-crypt device as usual.) (You should probably overwrite the whole device using direct-io on the first activation to initialize auth.tags. Otherwise any reads, including page cache, will fail on -EILSEQ - integrity error.) The above is in principle what crypstestup is doing for you. Authenticated filesystem is definitely better idea, but because I can guess in which environment you are trying to implement this I guess it is not an option... Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
