How does Cipher Feedback work?

How Cipher Feedback turns a block cipher into a stream-like mode

cipher feedback, usually written CFB, starts with a block cipher and an initialisation vector, then encrypts the previous ciphertext block to produce the next keystream segment. That means it behaves more like a streaming mode than a simple block-by-block transform. The important distinction is that CFB uses the block cipher as a keystream generator, not as a direct block substitution mechanism.

Because the next input comes from prior ciphertext, CFB can operate on smaller units than the underlying block size in some implementations. That makes it useful when you want incremental encryption and decryption without waiting for a full block of fresh plaintext to accumulate. It also explains why the mode is described as self-synchronising after enough data has been processed.

For a broader refresher on block cipher modes, IVs, and related primitives, the Cryptography Basics Guide is the best starting point because it connects CFB to the surrounding design choices that determine whether a mode is safe to deploy.

Why IV handling and feedback matter in practice

CFB only works correctly when the IV is treated as a required part of the mode, not an optional extra. If the IV is reused, predictable, or handled inconsistently between encryptor and decryptor, the first output segment can become deterministic or otherwise reveal structure that should have stayed hidden. In practice, this is one of the main reasons teams get into trouble with legacy mode implementations.

Feedback also means that corruption is not neatly confined to a single block. A flipped bit or truncated segment can disturb the current output and at least the next decrypted segment, which is why CFB is often described as having error propagation. That property is useful to understand operationally: it does not usually destroy the entire message, but it can still make downstream plaintext unreliable until synchronisation recovers.

Protocol rules matter because CFB is not a plug-and-play replacement for every other mode. The block size, segment size, IV construction, and padding expectations all have to match what the surrounding protocol or library expects. When those details are vague, the mode may still “work” in testing while failing to provide the security or interoperability the system needs.

When CFB is appropriate, and when it is not

CFB is best understood as a compatibility and streaming-oriented mode, not as a default modern choice. It can still be perfectly valid when an existing protocol requires it or when incremental processing is more important than the operational properties of other modes. But if you are designing a new system, you should compare it against authenticated encryption modes before deciding that legacy confidentiality-only protection is enough.

The key question is not whether CFB encrypts data, but whether it fits the system’s error model, message framing, and integrity requirements. CFB provides confidentiality through feedback, but it does not itself add authenticity or tamper detection. If an attacker can modify ciphertext in transit, the mode does not prevent manipulation, it only determines how that manipulation surfaces during decryption.

The implementation decision should therefore be driven by the protocol contract. If the protocol already specifies CFB, follow it exactly. If you are free to choose, use the simplest mode that gives you both confidentiality and integrity rather than relying on confidentiality-only construction and hoping surrounding controls will compensate.

Risk and Threat Considerations

CFB’s main security risk is not that the mode is inherently broken, but that small implementation mistakes can produce predictable output or fragile decryption behavior. Reused or mishandled IVs, inconsistent segment sizes, and unauthenticated ciphertext handling can all turn a confidentiality mechanism into an avoidable exposure point.

Failure mechanism: The mode feeds prior ciphertext back into encryption, so any IV weakness or ciphertext corruption can influence the next output segment and create visible structure, incorrect plaintext, or synchronisation problems in downstream processing.

Impact: An attacker or implementation bug may be able to expose patterns, trigger decryption failures, or alter application behavior in ways that are hard to diagnose because the failure appears as a mode-level issue rather than an obvious application error.

Practitioner Guidance

What to verify: Confirm that the IV handling, segment size, and block cipher parameters are identical on both sides of the exchange. If the implementation inherits CFB from a protocol, check the protocol document before trusting the library default.

Common mistake: Teams sometimes assume that “encrypted” means “safe to transmit,” but CFB only gives confidentiality. If the data must resist tampering, select or wrap the design with integrity protection rather than assuming the mode itself will detect modification.

Practitioner takeaway: CFB is a mode-compatibility choice with specific operational constraints, not a general-purpose modern default, so the safest decision is to treat IV discipline, parameter matching, and integrity requirements as first-class design checks.

Related resources from NHI Mgmt Group

• How does a Linear Feedback Shift Register work?
• How does Output Feedback Block work?
• How does Rivest Cipher 4 work?
• How does Tweakable Block Cipher work?