If you've dealt with symmetrical algorithms, such as DES, 3DES or Rijndael, you're probably aware that you must supply a key and and IV to encrypt/decrypt. If you're not aware of this, you shouldn't be writing code that works with cryptography :). Everyone knows what the key is, but what's the IV? IV stands for initialization vector. IVs are used to “jump start” the cipher stream. Not clear? It helps to understand how to look at a cipher.

Think of a cipher as a random mapping from a piece of plaintext to a piece of ciphertext. Most modern ciphers are block ciphers: they work on n-bit blocks of plaintext at a time. Thus we can imagine a cipher such as Rijndael (which uses 128-bit blocks) to have a huge dictionary: one entry for every possible plaintext and it's corresponding ciphertext. In reality, there's not that much memory available, so instead the ciphertext is computed.

So lets take a sample message: “Hi Bob, how are you?” We'll split that into blocks: “HiBob HowAr eYou?”. With a particular key, the ciphertext might be “LaAHz IAtXm LyJxr”. Everything's nice and safe. Now, let's send another message: “Hi Bob, game?” This becomes “HiBob Game?”, and ciphertext “LaAHz KozhW”. Notice a problem? Since the first two blocks have the same plaintext, they will have the same ciphertext. If an attacker knows the format of the message, he can start to guess the first part of our messages (since “HiAlice” and “HiEve” would have different first blocks). This can get worse.

Imagine that the messages are orders, and the first block is the item number, the second the price, and the third the quantity. Now an attacker can determine (say by entering an order and looking at the output -- called a chosen plaintext attack) which ciphertexts correspond to which items/prices/quantity. Modification of the messages can be stopped by a digital signature algorithms. But what about reading? Enter the cipher mode.

The cipher mode I've been describing is ECB, Electronic Code Book. It's exactly as it sounds -- basically a big lookup. Each block is processed by itself. As shown, this isn't very secure for most applications. The most basic improvement is the CBC mode. (There are other modes as well, but CBC works for this article.)

CBC stands for Cipher Block Chaining. CBC takes the ciphertext of the previous block, and XORs it with the current plaintext block before encrypting it. Thus the ciphertext block for “10000” won't always be the same, but it'll depend on what the preceeding plaintext is. So, the message “12345 10000 29500” will have completely different ciphertext than “54321 10000 29500”.

So, using the previous block is easy, but what about the first block? This is where the IV is used. The IV is the “previous encryption“ for the first block. So when we encrypt “HiBob“, we're going to first XOR “HiBob“ with our current IV.

IVs are not sensitive. You do not need to hide the IV. Many times, a unique message ID is used as an IV, since many applications require a unique ID anyways. It's perfectly fine to send along the IV as the first piece of ciphertext. Thus, we read the first block, and use that as the IV when decrypting. This makes managing the IV very simple, since it's right there with the message.

However, just remember to never reuse an IV! If you reuse an IV, it defeats the purpose, since the benefit of the IV is negated. Any given plaintext will always be the same with a given key and IV. But since IVs aren't sensitive, and easy to manage, this shouldn't be an issue.