1
$\begingroup$

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).

Improve this question
$\endgroup$
2
  • $\begingroup$ Do you mean "The problem with CBC" in the second paragraph? $\endgroup$
    – otus
    Apr 11, 2016 at 11:15
  • $\begingroup$ oops yeah, completely failed that. @yyyyyyy thanks for the edit. $\endgroup$
    – My1
    Apr 11, 2016 at 13:29

1 Answer 1

Reset to default
3
$\begingroup$

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.

Improve this answer
$\endgroup$
8
  • $\begingroup$ well reading wouldnt even be THAT much of a problem because the cipher is being chained making decryption parallelizable etc. the complete kill with this would be OFB which would literally need complete decryption. back to your answer. sector-driven CFB would be an Idea but how large or small should those be? you cant just completely de- and re-encrypt 2GB of data that quickly (for example) $\endgroup$
    – My1
    Apr 11, 2016 at 13:31
  • 2
    $\begingroup$ @My1 Disk sectors are actually quite small. Most sectors are just 512 or 4Ki bytes (and 2KiB for optical drives). That means that encryption/decryption per sector would not slow things down much. So the sector size is a given and relatively small; it's not something to be determined by the disk encryption scheme. $\endgroup$
    – Maarten Bodewes ♦
    Apr 12, 2016 at 11:05
  • $\begingroup$ but then again why not just instead of creating pseudo IVs all the time, why not just use counter Mode, which just needs a single IV/nonce with the counter doing the rest. and when going into overdrive, one could use GCM (which iirc bases on CTR) for auth'ed AES $\endgroup$
    – My1
    Apr 12, 2016 at 11:51
  • $\begingroup$ @My1: the problem with GCM (or any mode that expands the ciphertext) is that the disk provides (say) 4k sectors, and the OS using the disk expects 4k sectors, and so there's no additional space for nonces, IVs or tags. This (plus the possibility that someone might write to the disk sector a related plaintext) is the problem that makes disk encryption difficult; if we could expand the disk sector by 256 bits, then it's an easy problem with off-the-shelf answers... $\endgroup$
    – poncho
    Apr 12, 2016 at 13:09
  • $\begingroup$ well any non-ECB mode requires at least an IV/Nonce which is used only once for the whole encryption stuff, no matter whether CTR or GCM or CBC. but while cbc does base on IV/prev block CTR/GCM bases on nonce/counter and the counter can simply be the sector number. in both cases you just need an initial sector to store the IV/nonce $\endgroup$
    – My1
    Apr 12, 2016 at 13:47

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.