[dm-crypt] dm-crypt overhead

Milan Broz gmazyland at gmail.com
Thu Mar 1 18:41:04 CET 2018

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?


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


More information about the dm-crypt mailing list