6
$\begingroup$

I would like to know the domains or specific applications where using AES-CBC is not advised due to any drawbacks like sequential encryption of AES-CBC ?

$\endgroup$
  • 4
    $\begingroup$ Hint: consider a large encrypted file, of which a small fraction needs to be updated. $\endgroup$ – fgrieu Sep 23 '14 at 16:47
  • $\begingroup$ @fgrieu, isn't this breaking the encrypted file a part? ... $\endgroup$ – Giliweed Sep 23 '14 at 16:52
  • $\begingroup$ @fgrieu, can an encrypted file be divided into parts and each being used/send differently? .....how? $\endgroup$ – Giliweed Sep 23 '14 at 16:54
  • 2
    $\begingroup$ @Giliweed That’s exactly what fgrieu is hinting at, duh! In fact, I think fgrieu’s hint is a brilliant example. When dealing with large files where only tiny fractions need frequent update, you’ld definitely want to choose something different. Just imagine someone trying to implement and use CBC for HD encryption… if that makes you grin, you’ve understood his hint! ;) $\endgroup$ – e-sushi Sep 23 '14 at 18:03
  • 1
    $\begingroup$ An important consideration related to the sequential nature is performance. AES-CTR may be significantly, possibly multiple times, faster than AES-CBC encryption. $\endgroup$ – user4982 Sep 23 '14 at 18:55
21
$\begingroup$

CBC does not perform authentication

This property makes it less suitable for places where authentication is required, basically any transport protocol. TLS uses CBC, but by default performs authentication over the plain text instead of the ciphertext, which opened up a host of attacks. CBC can be used here, but it is error prone and may require an additional key for calculating a (H)MAC.

CBC is more error prone than other modes of encryption to error oracles, even if padding oracles (see below) are not feasible. See the paper "Error Oracle Attacks on CBC Mode" by Chris J. Mitchell for more information.

CBC doesn't let you pre-calculate a key stream

Pre-calculated key streams let you XOR plaintext with the pre-calculated stream to provide encryption. For instance AES-CTR makes it possible to let you use very low latency encryption for protocols.

CBC doesn't allow you to perform parallel encryption

As each block is depending on the previous block, all the way up to the last block, it is impossible to perform AES using multiple threads at the same time. This is a performance bottleneck which may invalidate AES-CBC on many systems where performance is required (and that do not have implicit parallelism).

CBC doesn't allow you to skip bytes

As each block is depending on the previous block, it is not possible to start encryption in the middle of a stream (decryption is possible though). This means that CBC is less suitable for re-encrypting parts of a file. Nor does this allow you to easily skip frames in e.g. video or audio play back.

CBC requires padding or ciphertext stealing (CTS)

Padding has many issues: it requires additional block encrypts and will require additional space. If CTS is available (it isn't usually) it requires at least one block, although the IV may be used as well if that is send to the other side. Regardless, CBC may have issues where a minimum number of bytes need to be send, or when a minimum number of block encrypts is required.

Besides that, CBC with padding applied may be vulnerable to padding oracle attacks. These may even be present on applications that are protected with a MAC if decryption is performed before authentication is established. This includes all transport protocols.

CBC requires an IV that is unpredictable to an attacker

This may be an issue where no fast random number generator is available and/or where additional block encrypt (to create an encrypted IV) is not feasible or wanted. This may be an issue on embedded platforms. As it is not directly possible to use a counter, CBC cannot be directly used on places where the IV can be derived from some identifier present in the protocol. It is also tricky to use an IV that is smaller than the block size.

CBC ciphertext errors do not propagate much forward nor do they travel backwards

This is not a feature that is requested a lot, but where it is, CBC does not provide it. Instead a mode such as bi-IGE (bi-directional Infinite Garble Extension) must be used.

Single bit errors in the ciphertext may affect up to 129 bits of plaintext

On the other hand, a single bit error in the ciphertext will garble the a complete block + a bit in the next block. This means that CBC is less suitable in places where error correction is calculated over the plaintext. CTR would be more suitable in such situations.

CBC may fail harder if you use a key too long

If you use a key for close to $2^{n/2}$ blocks, you expect a collision which leaks a block's worth of data. In contrast, CTR-based modes fail more gracefully: as long as you don't reuse a counter value, they only lose indistinguishability at that point.

$\endgroup$
8
$\begingroup$

There are several scenarios where you wouldn’t want to use AES in CBC mode.

In CBC mode, each block is dependent on a previous one. As @fgrieu nicely hinted at in his comment, using CBC means that if you have a large, encrypted file and you only want to update/change/modify a tiny fraction of it, you would have to follow the decrypt-modify-encrypt path each time you modify something in that file. This isn’t ideal from almost any perspective (it costs more time, resources, etc.)

So, when dealing with large files where only tiny fractions need frequent update, you would definitely want to choose something different.

Another prime example where you’ld want to avoid using CBC would be disk encryption. Sure, there’s a CBC mode in disk encryption too… but some good reasons make me prefer XTS over CBC in this case.

Anyway… given enough time and effort, I could probably to come up with a whole list of scenarios where CBC is “not the optimal choice” (including reasoning), but that would tend to make the answer too broad.

But as long as you’re understood that – in CBC – every block depends on another one, I’m confident that you’ll be able to come up with such a list yourself, or (at least) decide if CBC is the most optimal choice for certain scenarios.

$\endgroup$
  • $\begingroup$ In disc encryption, it is actually relatively common to use CBC. (For example when complemented with Encrypted salt-sector IV). $\endgroup$ – user4982 Sep 23 '14 at 18:58
  • $\begingroup$ @user4982 I’ld say that the mode that's “relatively common” for that is XTS. But – looking at LRW, XEX, CMC and EME – that probably depends on how one interprets the words “relatively common”. $\endgroup$ – e-sushi Sep 23 '14 at 19:37
  • $\begingroup$ dm-crypt used to do AES-CBC-ESSIV. For this reason, the most versions of Linux and the most versions of Android use it. The latest dm-crypt on Linux has switched to XTS. I also tend to prefer XTS, then again, in some ways wide block modes (XCB, EME2) would be superior to XTS, but most wide block modes modes have not been sufficiently properly studied, standardized, or accredited to get commonly implemented. Anyway, this is a side-track. My intent was just to point out that CBC mode has it uses in disc encryption. $\endgroup$ – user4982 Sep 23 '14 at 19:46
  • $\begingroup$ @user4982 Don’t get me wrong – I’m all with you (as long as the IV is secured via ESSIV; as you noted). The only reason why I commented XTS could also fit “relatively common” is that XTS is supported by BestCrypt, dm-crypt, FreeOTFE, TrueCrypt, DiskCryptor, FreeBSD's geli, OpenBSD softraid disk encryption software, and Mac OS X Lion's FileVault 2. OTOH: you may well be more correct than me. I don’t have feature-lists of all disk encryption software out there and I can’t look into people’s computers. Who knows what’s relatively common? In the end, everyone chooses his own preferred poison… ;) $\endgroup$ – e-sushi Sep 23 '14 at 20:13
-2
$\begingroup$

CBC is one of the five confidentiality modes of block cipher. It needs one IV (Initialization Vector). The IV must be same length to the blocksize of the algorithm (e.g. 128bit for AES). The IV is done exclusive-ORed with the first plaintext block P1. The result of the first XOR operation is C1. Next C1 is exclusive-ORed with the second plaintext block P2. And this process goes on till the last plaintext block is processed. So the reason way I'm saying this that CBC is all about giving the plaintext a non-recognizable look. It can be used in DES, TripleDES, AES and other block ciphers. If you want your plaintext to be simple then don't use it. The reason why AES is used is to keep data/file encrypted that is keep it secure and CBC (and the other modes as well) gives a little bit more security to AES.

EDIT:

As from fgrieu's and e-sushi's comment there is one area where AES-CBC mode should not be used that is when part of a large data is needed frequent processing (reading and writing). If CBC is used then the whole data (starting from the fist block to the needed block) needs to be decrypted first to get the certain part of the data, since each block is depended on the previous cipher block. So choosing a different mode might help in this case.

$\endgroup$
  • $\begingroup$ cleaned up comments relating to previous version of the answer $\endgroup$ – mikeazo Sep 29 '14 at 16:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.