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 ?
3 Answers
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.
- 96,351
- 14
- 169
- 323
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.
- 18,161
- 12
- 87
- 240
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.