Score:0

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

pf flag

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.

kelalaka avatar
in flag
new IV per block....
phantomcraft avatar
pf flag
@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?
Score:4
cn flag

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.

fgrieu avatar
ng flag
The last sentence in the answer states a sad and important truth: sector-level disk encryption does not provide authentication.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.