In NIST SP800-38A: Recommendation for Block Cipher Modes of Operation CFB can be used with a parameter s - the size of a data segment in bits - which determines the amount of key stream material that is produced per block.

API's often also have parameters to at least generate a segment 8 of bits or a segment of the same size as an entire block - which is the maximum for s. Usually s is of course limited to multiples of 8 as the input/output is specified in bytes.

Usually OFB can also be parametrized this way, but it doesn't seem that the use of a parameter s (with a different value from the block size) is a recognized mode of operation in the standard.

What is the use of parameter s? Does it just have to do with error propagation?


Actually, s is in CFB mode to handle transmission channels for the encrypted data that can add or drop individual bytes.

In the olden times (say, the 70's), it was common to transmit data over serial channels, for example, RS-232. These channels were not perfect, and one common error we see is that if the transmitter sent 7 bytes, the receiver might get only 6 (or possibly 8); this would happen only on occasion, but it was a definite possibility.

Now, consider what would happen if we sent CBC-encrypted data over such a channel. The first time we drop a byte, what would happen is that the block boundaries that the encryptor and the decryptor assume would not line up; what the encryptor thought was the first byte of the next block, the decryptor would assume is the last byte of the previous block. The decryptor would get gibberish, and (this is the important point) there is no mechanism for them to ever resync.

That is what s in CFB mode is for; if we set s=8, then after a drop (or add) error, the decryptor will get the next 8 bytes (8 assuming DES; this is the 70's after all) as gibberish, but then it will start to decrypt correctly (assuming, of course, that the transmission channel doesn't give us any more errors).

Now, times have changed; we don't deal with such channels that much any more. In addition, we are considerably more sensitive to what an active attacker could do; if we did need to deal with such a channel, we're more likely to break up the plaintext stream into a series of records, encrypt (and MAC) each record separately, and insert a noncryptographical resyncing protocol (e.g. byte-stuffing in end-of-record markers) on top of it. That way, an error may cause us not to receive a record or two, but nothing more (and the attacker could not introduce any bogus data).

As for the s parameter in OFB mode, that is universally recognized as a bad idea; using an s < n vastly increases the probability of OFB falling into a short loop, with no benefit in compensation.

  • $\begingroup$ Thanks for the extensive answer! I think that OFB8 being universally recognized as being a bad idea does place a few API designers and user applications in a different universe though. I did read about the short loops yes, I presume that that was the reason why NIST did not standardize OFB8. $\endgroup$
    – Maarten Bodewes
    Nov 13 '14 at 16:22
  • $\begingroup$ @owlstead: ok, universally recognized by the cryptographically clueful. In any case, while I can come up with plausible scenarios where CFB mode with s=8 is the best solution, I cannot think of any scenario where OFB mode with s=8 is any better than, say, OFB mode with s=n. $\endgroup$
    – poncho
    Nov 13 '14 at 16:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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