I was wondering if CFB can be better than OFB in any ways. I would like to know in what cases one would use CFB over OFB.

  • 1
    $\begingroup$ They're both silly; there's no reason to use either one instead of CTR, and while you're at it, you should be using an authenticator, and generally use an authenticated encryption scheme. AES-GCM is an example; crypto_secretbox_xsalsa20poly1305 is another. $\endgroup$ Apr 8, 2018 at 15:40
  • $\begingroup$ @SqueamishOssifrage There is a reason not to use CTR: CTR only has a 96 bit IV space, whereas CFB and OFB both have a 128 bit IV space. That is relevant as the moment you ever use CTR with the same key and same IV for different data, you killed your security and this is much more likely to happen with CTR. Also AES-GCM is also just AES-CTR with an additional auth performed at the end (you can implement AES-GCM on top of AES-CTR easily). And CTR is limited to 64 GB of data; if you want to encrypt more, you get an even smaller IV space. $\endgroup$
    – Mecki
    Apr 9 at 10:21

3 Answers 3


The only reason I can imagine why one would prefer CFB over OFB or CTR is error propagation. Another reason may be technical issues with the relieability of the transmission line.

This comes from the fact that if you flip a single bit in an OFB ciphertext then you only get the same bit flipped in the underlying plaintext. But if you flip a single bit in CFB mode, you get the bit flipped in the plaintext and get the following block to decrypt to gibberish. So there's a larger chance of you detecting a manipulation of the ciphertext because the effect on the plaintext is bigger.

However the above reason stems from the dark ages of cryptography, where authenticated encryption was usually done ad-hoc or not at all, so people actually relied on these error propagation properties. These days, using anything but CTR is pointless, because CTR allows very nicely for SIMD parallelization and error propagation as a property is kinda irrelevant because the authentication tag will catch any modifications.

  • 3
    $\begingroup$ Addition: CFB has a drawback worth mention compared to OFB: a collision of ciphertext blocks leads to a potentially exploitable relation for the plaintext blocks that follow (their XOR is also the XOR of the ciphertext blocks that follow), and is observable if it occurs. This becomes an issue for mere gigabytes of data for 64-bit block ciphers (like 3DES, Gost..). There's a comparable issue with CBC. By contrast, OFB remain secure for a petabyte, as long as the key is not used for multiple IVs. CTR brings several further improvements. $\endgroup$
    – fgrieu
    Apr 8, 2018 at 13:05
  • $\begingroup$ But OFB & CBC are self recovering/ synchronization modes, whereas CTR/ OFB will not decrypt correctly if a block is lost during transmission? $\endgroup$
    – crypt
    Nov 17, 2022 at 17:24
  • 1
    $\begingroup$ @crypt in any modern system, where you employ some form of proper authentication beyond hoping for error propagation, you also can't handle a lost block because you can't verify the data as untampered. So the self-recovery for the synchronization doesn't matter there. However, I could see extremely niche scenarios where potentially tampered-with data is preferable over having to retransmit a whole packet. In those situations, self-recovering encryption modes might indeed be preferable over CTR/OFB. $\endgroup$
    – SEJPM
    Nov 18, 2022 at 17:44

Advantages of CFB over OFB:

  1. Ability to parallel decryption, and hence it has better performance.
  2. Ability to random read access during decryption. There is no need to calculate all previous (expensive) steps to decrypt some part of information.
  3. Presence of error propagation, though it lasts only for some parts of the message. In my opinion, it's not a big advantage.

Advantages of OFB over CFB:

  1. Ability to calculate almost all the work in advance and perform only xor with cipher text.
  2. Absence of error propagation.

CFB allows random access. I can start decrypting at any offset, because all the information I need to decrypt a block is the encryption key, the IV, the encrypted block itself and the next encrypted block. With OFB I have to calculate all values up to the block I want to decrypt, even though I don't care for anything in between and won't ever decrypt it.

And contrary to what people keep claiming, it's not always better to use CTR. Either form of chaining is only secure if you never use the same key and same IV for different data. In case of CBC, CFB, or OFB, as long as this is guaranteed for the first block of data, it is pretty much guaranteed for the entire chain (at least until you encrypt so much data, that you run into birthday attacks). In case of CTR, though, every block is like a chain of its own, that means you must ensure this condition is true for every single block and if you cannot guarantee that, you cannot guarantee that your CTR encryption will be secure. This is easy to do if you are encrypting data, that naturally has a higher-level block structure with block numbering (like when encrypting file data blocks for an encrypted file system, one of the first major uses for CTR) but it's nowhere as easy when encrypting a stream of data of unknown length and with no higher-level structure and with no history on previous key and IV data.

  • 2
    $\begingroup$ "OFB uses the cipher for encryption and decryption, so both modes must be implemented." - Output Feedback Mode also uses the underlying block cipher only in the encrypt direction. $\endgroup$
    – poncho
    Apr 9 at 12:28
  • $\begingroup$ @poncho Oh, thanks for pointing this out. I though OFB is also using it both ways like CBC and only CFB and CTR use it one way. $\endgroup$
    – Mecki
    Apr 9 at 17:27

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.