In which cases should the IV be kept secret?

Question

When must an IV be kept secret?

There is an ambiguity in the way that the lack of need for secrecy of the IV is described in multiple places. Does this ambiguity suggest that there are, in fact, situations in which the IV must be kept secret? Or is it a quirk of language that has persisted across several popular sources?

The (ISC)2 Guide to the CISSP states (emphasis mine):

There is no need for the IV to be secret, in most cases, but it is important that it is never reused with the same key.

Crypto.StackExchange:

IV usually does not need to be secret, However, in most cases, it is important that an initialization vector is never reused under the same key.

Wikipedia:

An initialization vector has different security requirements than a key, so the IV usually does not need to be secret.

I understand the role the IV plays and the reasons that is is generally considered to be non-secret information. I am curious if there are situations in which it must be treated as secret information, or if this is merely a linguistic no-op that has gotten repeated.

Answer 1

Normally, in a properly designed cryptographic system, everything that must remain secret is either actual data (and the system exactly aims at preserving that confidentiality) or a key. Everything else ought to be public or at least publishable with no ill effect, as per Kerckhoffs' principle.

Now it so happens that a number of cryptographic systems are expressed as iterative processes, starting with an "initial value" (or "initialization vector"), i.e. an "IV". It is conceivable that in such a system, the IV is a key. A contrived example would be a hand-made stream cipher with a hash function:

• A state s is initialised to some value.
• The stream cipher produced pseudo-random bytes by repeatedly hashing s: the first bytes of output are H(s), then H(H(s)), and so on.

Such a stream cipher is then an iterative process that repeatedly produces the next value of the "running state" by hashing that state. The starting value for the state is thus an initial value in the strict sense of the term, and is also the key for the stream cipher, hence the need for secrecy.

This is, however, a quite contrived example. This stream cipher is atrociously weak in several ways (don't use it!). In a properly designed cryptographic system, we really prefer it when keys are reusable: keys that can be used only once tend to imply issues (it was one of the problems with RC4). Instead, we prefer keys that can be used several times (e.g. to encrypt several messages), possibly along with other values that need not be secret, but must be changed each time. This is what normally happens with encryption system: a secret key, that can be reused for several messages, and a per-message "nonce" that must be generated anew for each message, but needs not be secret; hence, the nonce can be transmitted along with the message. The "IV" in most encryption systems fulfils this "nonce" role.

---

In a more conceptual point of view, the notion of "IV" is not precisely defined. Thus, expressing an absolute such as "IV never need to be secret" is bound to anger somebody, somewhere, would used an IV in a slightly exotic way and found a situation where something can be called an "IV" and still requires secrecy. Using a phraseology like "usually" or "in most cases" is a simple way to avoid triggering an acrimonious debate.

Answer 2

One example of a situation where an "IV" needs to be secret can be found in one of the original papers on the HMAC construction:

• Bellare, Mihir, Ran Canetti and Hugo Krawczyk. 1996. "Keying hash functions for message authentication." http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.134.8430

Quoting pages 4-5 (my boldface):

The first obstacle that one faces when coming to design a MAC scheme based on a cryptographic hash function [...] is that the latter usually do not use any cryptographic key. Rather, they are public functions that anyone can compute without the involvement of keys and secrets. This is in sharp contrast to a MAC function, which uses a secret key as an inherent part of its definition. Our approach to solve this problem is to key these hash functions through their initial variable (IV) (for details see Section 2). That is, the usually fixed IV defined by these functions is replaced by a random (and secret) string which becomes the key to the MAC.

Classic hash functions like SHA-2 have an "IV" as well, but it is not normally exposed as an argument to the users of the hash function—it's an internal parameter that the definition of the hash function sets to a fixed, constant value for the hash function instance. The purpose of a hash function's IV is not obviously analogous to that of the IV in a block cipher mode, but the term is nevertheless the same.

So the paper first defines an "NMAC" construction that works by modifying a hash function like SHA-2 to take the IV as a user-supplied argument instead of a fixed value. But since many users can't or won't do that, then they show the now-familiar HMAC construction as a variant that works off an off-the-shelf hash function (section 5, p. 13):

The NMAC construction presented in Section 4 requires direct access to code for the compression function (rather than for the overall hash function), in order to key the IV. Such a change is trivial for functions with well-structured code like MD5 (see [Ri]). However, in some cases one would still like to avoid even those minimal changes, and use the code (or hardware implementation) as is. Here we present [HMAC,] an adaptation of NMAC that achieves this goal.

---

I separate this part of my answer because it's an opinion.

Your question and my example ties to a gripe I have against the popularity of the term "IV." It's a term that pertains to implementation details of an algorithm (a value that's used to initialize some data structure used in the algorithm), and not to the interface of a function (what a user who treats it as a black box most cares about!). When describing the interface of a cryptographic scheme, I think it's just clearer to avoid the term "IV" and use terms whose definitions or connotations pertain to the interface or contract of the scheme. E.g.:

• A nonce—a non-secret value that the user must promise must not be reused across multiple calls.
• A random salt—a non-secret value that the user must promise is chosen at random for each call.

The latter term is not normally used in the context of ciphers and modes like CBC, but I think it's a better choice than "IV." In any case, when you see the term "IV" I'd recommend against assuming that it implies a non-secret value, and rather verifying that this is true. I suspect that the text that's confusing you is written the way it is because of similar concerns.