Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

This question already has an answer here:

I'm looking into encrypting with AES using a 256bit key, and I notice that a number of methods in various languages, for instance http://php.net/manual/en/function.openssl-encrypt.php, and I notice that the IV parameter is optional. Does this mean that I can fully implement AES encryption/decryption with a single 256bit string as the key? What purpose does the IV serve, and will security be significantly reduced if I omit it?

Apologies for my ignorance, I've been thrown head first into a task which I'm feeling pretty disorientated about, trying to piece it all together :)

Thanks!

share|improve this question
    
Side-note: Don't write symmetric crypto before you learn what authenticated encryption is and why you should use it. –  CodesInChaos May 2 '13 at 8:57
add comment

marked as duplicate by Terry Chia, Adnan, Antony Vennard, AJ Henderson, lynks May 3 '13 at 12:38

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

2 Answers

up vote 5 down vote accepted

If you use each key only a single time, not using an IV is fine. If you use a key multiple times you should use a different IV each time, so a (key, IV) pair isn't reused.

The exact requirements for the IV depend on the chosen chaining mode, but a random 128 bit value is usually fine. It should be different for each message you encrypt. Store it alongside the ciphertext, typically as a prefix.

share|improve this answer
1  
Hmm, I guess I don't understand the purpose of the IV at all then. I plan to use the key multiple times in 2 way communication. Surely the IV needs to match at each end point, do I need to communicate the new IV between them constantly? This seems impractical so I'm fairly sure I'm missing an obvious piece of the puzzle. Thanks for your answer so far, I'm stupider than you predicted though :) –  DanH May 2 '13 at 9:03
2  
1) In two-way communication I'd use a different key for each direction. Use HKDF to derive them from a master key. 2) If you use CBC mode you need to communicate a new IV per message (like TLS 1.1+ does it) or in theory you could derive it from the message number. Look up the BEAST attack for why you need a new random IV per message. 3) Consider using SSL/TLS. Learning to do crypto correctly takes quite a bit of time and it's still error prone. If you just need two-way communication use the standard solution. –  CodesInChaos May 2 '13 at 9:07
add comment

Suppose you encrypt two messages with the same key, and the two messages begin with the same 16 bytes of plaintext. (16 bytes is the block size for AES, regardless of the key size.) Will the first block of ciphertext be the same? If it is, you're already leaking some information to the attacker. Whether this information is sensitive or not depends on your application, but it's already a bad sign. If the encryption leaks more than the sign of the messages, it's not doing its job.

The basic idea of an IV is to prepend a bit of random content to each message, in a principled way. How this works precisely depends on the mode. (The core AES operation only works on 16-byte blocks. A mode is a way to extend this to longer messages.) For example, with CBC, the encryption of each block is computed from the key, the plaintext block and the ciphertext of the previous block; for the very first block, the IV is used instead of the ciphertext of the non-existent previous block. The IV is normally sent in cleartext alongside the ciphertext, usually it is sent a the first 16 bytes of the encrypted message.

CTR mode technically uses a counter and not an IV, but operationally they work very similarly: a 16-byte random value is generated at random by the sender and sent at the beginning of the encrypted message. With CTR mode, reusing that value for another message is catastrophic, because CTR works by XORing the plaintext with a pseudorandom stream deduced from the key and counter. If you have two encrypted messages that use the same counter value, their XOR is the XOR of the two plaintexts.

There are more attacks against improperly-chosen IVs than I've listed here. Generate a random IV for each message (using a cryptographic-quality random generator, the same you'd use to generate a key), and you'll be fine.

There is one exception: if you generate a fresh key for each message, you can pick a predictable IV (all-bits 0 or whatever). You still need to use a mode with an IV (ECB is not fine, for example it exposes repetitions in the plaintext since two identical input blocks will have the same encryption). That's a rare case though (it arises for storage, not for communication).

Note that encryption a priori only ensures the confidentiality of the data, not its integrity. Depending on what you do with the data, this may be a problem. In particular, if an attacker can submit tentative ciphertexts to be decrypted, or can provide additional plaintexts to be encrypted, this can expose some information. Some modes such as EAX and GCM provide authenticated encryption: a ciphertext will only be decrypted if it's genuine. Use one of these if possible.

Note also that AES-128 is just as secure in practice as AES-256.

If you aren't comfortable with what you're doing, try to use some high-level library rather than grappling with the crypto directly.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.