# Which attacks can be avoided by the use of OFB instead of ECB?

For a file encryption program, I was told to use Output Feedback mode (OFB) instead of ECB (Electronic code book) mode.

Which attacks can I avoid by this choice?

-

– B-Con May 3 '12 at 18:02
When you are considering using a particular mode, it is generally useful to ponder what security properties you need from the mode, and whether that mode provides those properties.  What security properties are you looking for? – poncho May 3 '12 at 19:46
security for encrypted message and encrypted file. – goldroger May 4 '12 at 0:27
@JohnPaulParreño: I edited your question to be valid English, and still ask what you wanted to ask (I hope) ... sorry, I should have done this before, but I somehow missed your question. Please check that this is actually what you want to ask, and feel free to edit again. – Paŭlo Ebermann♦ Jun 5 '12 at 18:16
that's okay, It's more understandable now. – goldroger Jun 5 '12 at 18:22

## 3 Answers

OFB is a mode of operation to ensure confidentiality of messages a) longer than the block size of the encryption algorithm, and b) that can be re-broadcast. The motivation for these kinds of modes it to avoid the weaknesses that come from using plain ECB mode.

To be precise, the typical attack on ECB mode involves analyzing the ciphertext and looking for repeated blocks. Repeated ciphertext blocks mean repeated plaintext blocks, and knowing about repeated plaintext can help the attacker analyze the captured ciphertext. (Meaning that ECB is not semantically secure.) In some cases, this is enough for the attacker to learn all, or almost all, of the plaintext. OFB mode prevents this from happening by using randomized encryption to ensure that repeated plaintext within the message does not cause repeated ciphertext.

OFB is resistant to ciphertext errors in that if the ciphertext has bits modified in error, only the bits of the plaintext that directly correspond to the ciphertext are modified.

Because it OFB mode works like a stream cipher, it has the typical weakness that allows known plaintext to be easily modified by an attacker. (Ie, if OFB mode produces a keystream $K$, then the ciphertext $C$ is defined as $C_i := P_i \oplus K_i$, so if $P_i$ is known to the attacker then so is $K_i$, so they can create a new ciphertext $C'_i := P'_i \oplus K_i$ where $P'_i := P_i \oplus X$ and $X$ is a value chosen to produce the desired modified plaintext $P'_i$.) But since message confidentiality (the goal of OFB) does not encompass message integrity, this is not necessarily a big deal.

-

ECB mode is a deterministic encryption, instead in OFB if the initial vector is random choosed (and of course published with the cryptogram) is a random encryption. What's the matter with det.enc.? The problem is that if you encoded two time the same message you are going to get two time the same chipertext, so the adversary can understand that you said the same thing twice and she learned something!

-

Wikipedia has an excellent visual demonstration of the insecurity of ECB mode when applied to (potentially) repetitive data:

Here, the first picture on the left shows a simple cartoon image (Tux the Penguin). The second image is the same, but with the (raw, uncompressed RGB) image data encrypted using ECB mode. While details of the image are scrambled, the outline is still clearly visible because identical input blocks (found mainly in the areas with solid color) produce identical output in ECB mode. The third image shows the result of the same encryption process using a different mode that lacks this weakness, such as CBC, CFB, OFB or CTR.

Of course, if one used ECB mode to encrypt a compressed image, or some other data that lacks such obvious redundancies, then the patterns in the output would not be so obvious either. Still, many real-world files do contain redundancies — if they didn't, compression programs would be useless — and it's hard to be sure that those cannot be used by an attacker to compromise ECB mode encryption.

(To make the other modes secure even if the same key is used for more than one message, one also needs to include a suitable random IV or nonce. Presumably, the IV has been omitted from the example output here to make it match the length of the input.)

-
{"extraction_info": {"found_math": true, "script_math_tex": 0, "script_math_asciimath": 0, "math_annotations": 0, "math_alttext": 0, "mathml": 0, "mathjax_tag": 0, "mathjax_inline_tex": 9, "mathjax_display_tex": 0, "mathjax_asciimath": 0, "img_math": 0, "codecogs_latex": 0, "wp_latex": 0, "mimetex.cgi": 0, "/images/math/codecogs": 0, "mathtex.cgi": 0}, "config": {"markdown_headings": true, "markdown_code": true, "boilerplate_config": {"ratio_threshold": 0.18, "absolute_threshold": 10, "end_threshold": 15, "enable": false}, "remove_buttons": true, "remove_image_figures": true, "remove_link_clusters": true, "table_config": {"min_rows": 2, "min_cols": 3, "format": "github"}, "remove_chinese": true, "remove_edit_buttons": true, "extract_latex": true}, "english_confidence": 0.919074535369873, "perplexity_flag": "middle"}