# OFB or CTR mode without an IV

I'm reading the SSL specs here.

The interesting thing seems to be that RC4 is not re-keyed with a new IV for each message. The stream cipher state is simply carried over to the next record. Why is this secure? Shouldn't messages be encrypted with different IVs? Honestly, this is one part I don't fully understand about IVs: each message needs a different IV, but what counts as a message? A full stream of records? One record?

The CBC modes do have different IVs for each block.

My question is, how about a stream ciphery mode of operation, like OFB or CTR? Do I need new IVs for each smallish record, or can I do what SSL does with RC4 and just carry over the cipher state? Is that in any way insecure? WEP seems to do the new-IV-per-packet thing, and that seems to have caused its downfall. Why?

-
add comment

## 3 Answers

The answer from owlstead and its comments covers WEP part quite nicely.

This answer concentrates on CTR and OFB.

Strictly speaking, CBC, CFB, CTR, and OFB modes always use IV or counter. I'm assuming that the question was more like is it possible to use CTR or OFB mode securely without transmitting IV. I.e. for instance, start at all zeroes IV/counter and increment the counter for each message. This appears to be possible and secure. (As long as you're careful enough to never reuse same counter+key combination.)

## Details for selecting IV for CTR and OFB modes

The answer for IV(/nonce in CTR and OFB modes is found in document NIST SP 800-38A: Recommendation for Block Cipher Modes of Operation, which describes these modes. This document tells in Appendixes B and C various recommendations by NIST for choosing IV/counter for CBC, CFB, CTR and OFB. Long story short, for CTR and OFB modes, it is sufficient that IV/counter used is always unique for the same key, as long as it is also unique for each invocation of the encryption operation.

In other words, counter is ok for CTR and OFB. In OFB mode, it is not safe to use cipher text from a previous operation as IV, a practice that has been often used with e.g. CBC mode. The language of NIST specification may be misleading. There is evaluation of cipher modes of operation from Rogaway, which you may find easier to read and understand, and containing a lot of additional detail.

-
I'm assuming that the question was more like is it possible to use CTR or OFB mode securely without transmitting IV. I.e. for instance, start at all zeroes IV/counter and increment the counter for each message.. You seem to be the only person to have understood my question :) –  user54609 Oct 27 '13 at 21:05
For OFB things are more complicated as the nonce requirement is not sufficient: simply take a ciphertext block as an IV, and the keystream will repeat. Counter is fine (see my answer below). –  Dmitry Khovratovich Oct 28 '13 at 14:50
@DmitryKhovratovich: You're correct, in many cases definition of 'nonce' allows values which do not meet the requirements of all definitions of nonce. I'll fix my answer a bit so that it clarifies this point. –  user4982 Oct 28 '13 at 17:39
add comment

There is a number of ways how to generate the initialization vector (IV), and not all of them are secure for a particular mode of operation. The NIST recommendations are sometimes ambiguous and may lead to confusion. A comprehensive story of these issues has been recently told by Rogaway (see also excellent pictures there); let me summarize what should be said about CTR and OFB in the context of the IV generation (Sections 4.6, 4.7, 5.4).

First, by security I mean a rather strong model where the adversary selects a plaintext for the encryption and is then asked to tell apart a random string from the ciphertext. If the IV is random, it can not be chosen by the adversary; if it is a nonce, an adversary can choose it accordingly. If the probability of success is negligible up to huge amount of attempts with a fixed key, the mode is considered secure to chosen-plaintext attacks. This setting covers virtually all attacks that a good mode of operation that provides confidentiality (but not necessarily authenticity) should counteract.

Coming back to IVs, the OFB and CTR mode treat them differently even though they are somewhat stream-based. The IV in the OFB mode undergoes a number of encryptions; it can be easily proved secure if IV is random. However, a nonce-based OFB is generally insecure, as taking any previous ciphertext block as an IV destroys the security while being a good nonce (so the answer to one of your questions is definite "No"). A counter for the IV in OFB is fine and can be proved secure.

The CTR mode generates a keystream by encrypting an arithmetic progression starting with an IV. The best security is achieved when IV is selected such that no repetition in these values ever occurs; the NIST approach is good enough. A random IV is still fine, but not better; any previous ciphertext block should be fine and is likely to be secure, but it is unnecessary complication.

-
The document from Rogaway is very good. Compared to NIST's recommendation it is clearer, though it is quite much longer as well. I improved my answer by borrowing this detail from your answer. –  user4982 Oct 28 '13 at 20:00
add comment

What a message is depends on the protocol. As long as the state within the stream cipher does not repeat, the stream cipher is safe.

The problem with WEP (in this regard) was that it choose a new IV/nonce for each packet, but that it was possible for an attacker to repeat the nonces. This was due to the 24 bit size of the nonce.

-
While the 24 bit nonce size for WEP was a problem, what was worse was the way they used it; they used it in a way that allowed someone listening in to deduce bytes of the key. –  poncho Oct 27 '13 at 11:30
@poncho Yeah, I know that there are multiple issues with WEP, but I focussed in my answer on the one that was directly related to the repetition of the IV/nonce. –  owlstead Oct 27 '13 at 11:34
Why does CBC mode require new IVs for each ~kilobyte sized record in the same connection though? –  user54609 Oct 27 '13 at 11:57
CBC requires a random (to the attacker) IV for each message. The message size can be quite huge, certainly larger than a single internet packet. Could you please point to the specification/paragraph of the SSL specification you are reading? –  owlstead Oct 27 '13 at 12:05
Theoretically the maximum size is 65536 bytes, but usually libraries send records with size 4096 bytes and less. –  user54609 Oct 30 '13 at 13:50
show 1 more comment