7
$\begingroup$

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.

$\endgroup$

3 Answers 3

7
$\begingroup$

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

$\endgroup$
1
  • 4
    $\begingroup$ 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. $\endgroup$ Mar 21, 2012 at 0:45
7
$\begingroup$

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.

$\endgroup$
3
  • 2
    $\begingroup$ 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. $\endgroup$ Mar 13, 2012 at 11:54
  • $\begingroup$ However, to decrypt an isolated segment of an OFB encrypted cipher text, you must firstly advance the state to that position. $\endgroup$ Mar 13, 2012 at 11:55
  • 1
    $\begingroup$ @HenrickHellström: my mistake, see the updated answer. $\endgroup$ Mar 13, 2012 at 15:31
3
$\begingroup$

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.

$\endgroup$
1
  • $\begingroup$ 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. $\endgroup$
    – m33lky
    Mar 17, 2012 at 17:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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