How does dm-crypt in Linux make non-parallelizable encryption modes have all the 512-byte blocks different each other?

Question

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.

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.