liveBook · Manning

Initialization vector

As explained in Hacking Cryptography

An initialization vector is a public or nonsecret value combined with secret keying material to vary cryptographic inputs across messages.

An initialization vector (IV) is a nonsecret value combined with secret keying material to make cryptographic inputs vary between encryptions. It may be transmitted publicly: secrecy comes from the preshared key or cipher key, while the IV prevents every message from starting from the same cryptographic input. section 4.3.2

Figure 4.13 WEP setup showing preshared keys and initialization vectors as input to RC4
figure

In WEP, each packet carries a public three-byte IV. Sender and recipient concatenate it with the shared PSK to form that packet's RC4 key. section 4.3.2

The security requirement depends on the construction. WEP uses the IV like a nonce: a new IV is intended to ensure that packets protected by one remembered PSK do not reuse the same RC4 key. CBC mode likewise requires a unique IV for each message; a fresh IV must be generated rather than deriving the next one from prior ciphertext. section 4.3.2 section 5.6

Weak WEP IVs

WEP constructs an RC4 key as IV || PSK and exposes the IV with the packet. Certain IVs of the form [L, 255, X] interact with biases in RC4's key-scheduling algorithm. An observer who knows part of a packet plaintext can recover a keystream byte, collect many packets with weak IVs, tally key-byte guesses, and progressively recover the PSK. The IV is public by design; the failure is that chosen IV patterns expose an RC4 weakness. section 4.3.2 section 10.1.2

Reused CBC chaining value

A vulnerable encrypted HTTP session generates an initial AES-CBC IV, then uses the final ciphertext block of one request as the IV for the next. Because that next IV is predictable from observed traffic rather than freshly generated, an attacker can manipulate request plaintext around a cookie and guess the secret byte by byte. TLS 1.1 addresses this BEAST condition with a fresh IV for every underlying message. section 5.5.1 section 10.1.3

Treat IV handling as a cryptographic boundary:

  • Generate a new IV for every CBC-encrypted message; do not carry forward the prior ciphertext block as its IV. section 5.6 section 10.1.3
  • Do not assume a public IV is harmless when the underlying cipher has IV-dependent weaknesses; WEP's short weak-IV patterns enabled statistical RC4 key recovery. section 4.3.2 section 10.1.2
  • Keep the IV distinct from the secret key: recipients may use the transmitted IV with their secret material to reproduce the encryption input. section 4.3.2

How Hacking Cryptography covers it

How deep it goes
Traces IV handling through WEP key construction, RC4 bias exploitation, and CBC request chaining rather than defining generic IV algorithms.
Examples
Demonstrates public WEP IVs concatenated with a PSK and browser requests reusing a previous CBC ciphertext block.
What it assumes
Assumes familiarity with plaintext, ciphertext, keys, RC4, and CBC while illustrating IV behavior through executable attack scenarios.
What you can do after
Diagnose/debug with it by recognizing weak or reused IV handling that permits RC4 key recovery or BEAST-style plaintext guessing.
How it connects
Connects IVs to RC4, WEP, CBC mode, AES, TLS 1.1, BEAST, and known-plaintext attacks.

Also explained in

Compare how 3 books explain initialization vector →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Hacking Cryptography. The section links point to the parts of the book it draws on.