dm-crypt in Linux uses 512-byte blocks (disk sectors) having sub-blocks of encrypted plaintext for block cipher modes that are non-parallelizable:

"With the usual modes in cryptsetup (CBC, ESSIV, XTS), you can get a completely changed 512 byte block for a bit error. A corrupt block causes a lot more havoc than the occasionally flipped single bit and can result in various obscure errors."

/\ Source: https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions

It supports CBC, PCBC, OFB and CFB which are non-parallelizable.

I tested it here in my Linux system:

dd if=/dev/zero of=./img count=5242880 bs=1
dd if=/dev/random of=./key count=32 bs=1
sudo cryptsetup open --type plain --cipher aes-cbc-essiv:sha3-256 --key-file ./key --key-size 256 ./img blah
sudo cat /dev/zero > /dev/mapper/blah
sudo cryptsetup close /dev/mapper/blah

/\ I opened the disk image file in an hexadecimal editor and I could see that all the 512-byte blocks are different each other even if the plaintexts in whole disk image are uniform (zeroes).

My question is:

How dm-crypt makes all the 512-bytes blocks be different each other even if its plaintexts are the same?

If I encrypt something with CBC and split in 512-byte blocks for making seekable, the key and IV would be the same for each 512-byte block, so if I encrypt the same plaintext the blocks would be equal.

  • 1
    $\begingroup$ new IV per block.... $\endgroup$
    – kelalaka
    Feb 5, 2022 at 0:30
  • $\begingroup$ @kelalaka I know that ESSIV option in cryptsetup hashes the key to be used as IV, but is it added a counter to hash every 512-byte block? $\endgroup$ Feb 5, 2022 at 3:10

1 Answer 1


They simply use the sector number or some function of it as a tweak/IV. The sector number is known at encryption and decryption time, so it doesn't need to be stored with the ciphertext, which is good since there's no room for it.

All of these modes are actually highly parallelizable: disk I/O usually happens in multiples of at least 4K, and that can already be parallelized 8 ways. The lack of sub-sector parallelizability is a design feature. It's impossible for the driver to authenticate decrypted sectors because there is no room to store an authenticator, so it has to rely on higher levels to notice that the plaintext is wrong, and that's more likely to happen the more wrong it is.

  • 1
    $\begingroup$ The last sentence in the answer states a sad and important truth: sector-level disk encryption does not provide authentication. $\endgroup$
    – fgrieu
    Feb 7, 2022 at 9:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.