Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Why is CBC considered the canonical mode when there are streaming modes available such as CFB and OFB? One thing that I can think of is that in CBC you can easliy do range-based decryption. All you have to do is load the previous block (whose size is explicit). How would you do it in CFB/OFB? In my previous question I was thinking that in streaming mode it just uses the cipher block versus a larger disk block. Other things to note?

Diagrams to visualize this on wikipedia.

share|improve this question
up vote 7 down vote accepted

A reason to use CBC (or CFB) over CTR and OFB could be that they are a bit more misuse-resistant: If you use CBC with a repeated initialization vector, a (read-only) attacker only can get the fact that the plaintexts are equal up to some block, and not much more (and from the first different block the rest is different). With CTR and OFB, a repeated initialization vector (for the same key) leads to an identical key stream, and you have $E(P_1) \oplus E(P_2) = P_1 \oplus P_2$, which can be used for quite some analysis (depending on the messages).

(Of course, there are some chosen-plaintext attacks on CBC-mode when the initialization vector is predictable, as well as chosen-ciphertext attacks when there is no authentication (or the authentication doesn't include the initialization vector). So CBC isn't really the most misuse-resistant mode.)

share|improve this answer
Padding oracle attacks are extremely succesful against CBC mode nowadays, integrity protection/authentication should be the default, and should always be used in client/server models. – Maarten Bodewes Mar 21 '12 at 0:45

OFB and (to a lesser degree) CFB are malleable: an adversary knowing a selected portion of the plaintext and able to change the ciphertext can trivially change the alleged plaintext to something chosen, e.g. "no!" to "yes". CBC has a (small) degree of resistance to that.

OFB does not allow efficient decryption of an isolated segment of ciphertext (we need to know the IV, run the cipher for all previous blocks, and know or guess the position of the segment). CBC (and CFB) allow that (only the first block of the isolated segment is undecipherable).

CBC can be introduced as an improved version of ECB (the simplest mode), while CFB and OFB are a radical departure.

I conjecture this has conspired to make CBC popular.

Note: a previous version of this answer mixed OFB and CFB. That's fixed, thanks to Henrick Hellström.

share|improve this answer
In what sense does CFB mode not allow partial decryption of an isolated segment if cipher text? AFAICT it is exactly as possible for CFB mode as it is for CBC mode, that is, if you have cipher text blocks $ct_i$ and onwards, you can decrypt to get plain text blocks $pt_{i+1}$ and onwards, regardless if you use CBC mode or CFB mode. – Henrick Hellström Mar 13 '12 at 11:54
However, to decrypt an isolated segment of an OFB encrypted cipher text, you must firstly advance the state to that position. – Henrick Hellström Mar 13 '12 at 11:55
@HenrickHellström: my mistake, see the updated answer. – fgrieu Mar 13 '12 at 15:31

There is no good reason for it. It's just history.

CBC and CFB are sort of twins. They have the same essential flaws, just presented slightly differently. For example, you can truncate from the tail of ciphertext with impunity in CFB and from the head in CBC.

CBC became more or less the canonical mode because a lot of people used it in early protocols. CFB was used in PGP because it doesn't have padding issues.

I would be willing to believe that early on, someone decided that tail truncation was worse than head truncation or something, and just started using it. In a real sense, there's not much reason to use one of them over the other.

share|improve this answer
Streaming mode is developer friendly. You don't have to call cipher.finalize() at the end. You also don't need to create a special buffer (more room for error!) when you are reading from a device with a different block size and/or packet fragmentation. – m33lky Mar 17 '12 at 17:32

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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