CFB, CTR, choosing a mode, and how the key gets there

CFB — a block cipher wearing a stream cipher's clothes

Cipher Feedback (CFB) processes $s$ bits at a time through a shift register initialised to an IV. At each step the register's current contents are encrypted, and the leftmost $s$ bits of that encryption are XORed with $s$ bits of plaintext to produce ciphertext, which then feeds back into the register:

$$C_1=P_1\oplus S_s[E(K,\text{IV})],P_1=C_1\oplus S_s[E(K,\text{IV})]$$

and each subsequent step feeds the previous ciphertext unit back into the register. CFB eliminates the need for padding, can operate in real time on data as it arrives, and keeps the ciphertext the same length as the plaintext.

Here is the fact that is counterintuitive and therefore heavily examined: CFB decryption calls the encryption function $E$, never the decryption function $D$. The register is always run forward through $E$ to produce the pseudorandom mask; the actual recovery of plaintext is a plain XOR. The same is true of CTR, below. Of the modes in this lesson, only ECB and CBC ever call $D$ at all.

OFB — CFB's sibling, built for a noisy channel

Output Feedback (OFB) looks almost identical to CFB, with one change: the value fed back into the register is the preceding pseudorandom output, not the preceding ciphertext. That single change has a real consequence — a bit error in the transmitted ciphertext corrupts only the corresponding plaintext bit and does not propagate to later blocks, because the feedback never touches the ciphertext at all. That is exactly why OFB's stated niche is stream-oriented transmission over a noisy channel, such as a satellite link, where a single corrupted bit must not cascade.

CTR — no chaining, and every advantage follows from that

Counter (CTR) mode encrypts a counter value and XORs the result with a plaintext block; the counter increments for each block, and blocks are never chained to each other at all. SP 800-38A's one hard requirement is that no two blocks encrypted under the same key may ever share a counter value.

"No chaining" sounds like it should be a weakness. It is the source of every one of CTR's advantages: the counter values can be encrypted before the plaintext even arrives (preprocessing), independent blocks can be encrypted on separate cores in hardware parallel, block $i$ can be decrypted by random access without touching any other block, the scheme has a provable-security argument, and — because CTR (like CFB) never calls $D$ — an implementation needs only the encryption algorithm, which matters most for a cipher like AES whose decryption differs substantially from its encryption.

The nine modes, side by side

Beyond the five above, four more modes appear on the standards map: CMAC (a variant of CBC-MAC that adjusts the final block for authentication), OCB (authenticated encryption in a single pass over the data — roughly one block-cipher call per block covering confidentiality and authenticity together, fully parallelisable, and ECB-like in its parallelism without ECB's leakage, because a per-block offset destroys the identical-block property), CCM (CTR combined with CBC-MAC, for authenticated encryption where the data is available in advance) and GCM (CTR combined with a Galois-field MAC, for authenticated encryption on a stream). The CCM-versus-GCM discrimination — data in advance versus streaming — is precise, arbitrary-sounding, and exactly the kind of fact an MCQ is built from.

Choosing a mode for a stated application

Mode selection is itself examinable, applying the table below to a description in prose:

• Bulk file encryption, no special real-time constraint → CBC, the general-purpose default.
• A single value — one key, one nonce, one flag — with nothing to chain against → ECB is legitimate here, precisely because there is no second block for the leakage to expose.
• A high-throughput link that must scale across cores → CTR, because it is the only mode of these that is fully parallelisable on encryption as well as decryption.
• An authenticated channel that must also detect tampering → one of the authenticated-encryption modes (GCM if the data streams in, CCM if it is all available up front), not a bare confidentiality-only mode plus a hope.

Worked example — a session traced through a key hierarchy

A key distribution center (KDC) decides which pairs of systems are permitted to communicate and issues the actual session key. It is an entity, never itself a key. Each end already shares a permanent key with the KDC, established once, out of band. The sequence for A to reach B:

1. A sends the KDC a request to talk to B.
2. The KDC generates a fresh session key $K_s$ and sends A a message encrypted under A's permanent key $K_a$, containing $K_s$ plus a ticket for B — the same $K_s$, encrypted under B's permanent key $K_b$.
3. A forwards the ticket to B. B decrypts it with $K_b$ and now also holds $K_s$.
4. A and B communicate under $K_s$ for the life of that connection.

The session key encrypts user data for exactly one logical connection and is discarded the moment that connection ends — it never leaves a durable record to compromise later. The permanent key exists for one purpose only: distributing session keys, and it is reused across many sessions, which is exactly why it must be protected at least as well as any session key it will ever wrap. A related, narrower key — a key derivation key — is used specifically to protect the traffic between a station and a KDC while a session key is being negotiated, distinct from the long-lived permanent key.