# Disk encryption using AES-CBC: is reliance on previous block data a downside?

I have seen drives that boast that they use AES with CBC mode, which doesn't really make sense in my opinion, sure it's more secure than ECB (but actually, leaving security aside, ECB is better suited for disk encryption than CBC, explaining later)

The Problem with CBC is that you have a serious chicken and egg problem, which doesn't get very bad when working with most files, but gets problematic in disk encryption because it relies on the ciphertext of the previous block, wouldn't this be a serious performance bottleneck? Encryption parallelizing is one thing (although I think that encryption speed > HDD speed) but what happens if I change/remove for example block $1$? Won't the drive be unusable while re-encrypting ALL the remaining data?

ECB is junk security-wise, that one is true, but it doesn't rely on the previous data, which gives it an advantage, but then again CTR mode has the same advantage and XTS as well (aside from the last block which may rely on ciphertext stealing).

• Do you mean "The problem with CBC" in the second paragraph? – otus Apr 11 '16 at 11:15
• oops yeah, completely failed that. @yyyyyyy thanks for the edit. – My1 Apr 11 '16 at 13:29

As you know, it makes reading and writing the disk very slow if all the data in the drive is chained together. If so, writing to a drive of size $n$ at position $p$ will require $\Theta (n-p)$ time. One solution is the drive being divided into sectors, and each sector being chained. The IV of each sector can be attained using ESSIV. it generates IVs from a combination of the sector number with the hash of the key. This method is used in dm-crypt, OpenBSD's swap encryption, and FreeOTFE.