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.