27

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!

DanH
  • 405
  • 1
  • 5
  • 8
  • 2
    Side-note: Don't write symmetric crypto before you learn what authenticated encryption is and why you should use it. – CodesInChaos May 02 '13 at 08:57

2 Answers2

22

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.

Community
  • 1
Gilles 'SO- stop being evil'
  • 51,955
  • 14
  • 122
  • 182
  • Regarding "AES-128 is just as secure in practice as AES-256", from the comment you linked it certainly doesn't look so. It says it might be sufficient to use a 128bits key, but in no way it states that the security of a 256bits key is the same as the 128bits one. – Fabio A. May 19 '16 at 14:34
  • @FabioA. What are you refering to? AES-128 is just as secure in practice because there's no difference between unbreakable and unbreakable. The “more secure” aspect of AES-256 is only that it is “more secure” than the already-unbreakable AES-128. (Note: unbreakable assumes proper modes, otherwise all bets are off regardless of the key size. Unbreakable is with respect to current knowledge, otherwise all bets are off regardless of the key size.) – Gilles 'SO- stop being evil' May 19 '16 at 14:57
  • Unbreakable so far, but what do we know what will happen tomorrow? In that discussion I see mention of the quantum computers, for instance. Why should we use something mathematically less secure if more security is available at the cost of 128bits more, if those 128bits more are not a problem per se? – Fabio A. May 19 '16 at 15:36
  • @FabioA. We don't know what will happen tomorrow, which is why 256 bits isn't automatically an improvement on 128 bits. For example, one of the few known weaknesses in AES, a related key attack, applies only to AES-192 and AES-256 but not to AES-128. – Gilles 'SO- stop being evil' May 19 '16 at 15:52
16

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.

CodesInChaos
  • 12,084
  • 2
  • 41
  • 50
  • 2
    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 02 '13 at 09:03
  • 2
  • 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 02 '13 at 09:07
  • I don't agree. Without IV or a constant IV value, which is the same, the same message is encrypted in the exact same sequence of bytes. So if one see the same sequence of bytes in encrypted data we know it's the same clear text. This reaveals something from the encrypted information. With a random IV and an encryption chaining algorithm, the same clear text will be encrypted in a totally different byte sequence. The IV can be avoided in particular conditions that would be to long to explain here. – chmike Aug 27 '17 at 06:59
  • @chmike What exactly do you disagree with? "If you use each key only a single time..." avoids the "same ciphertext implies same plaintext" problem, because the attacker will only ever see a single ciphertext for each key. – CodesInChaos Aug 27 '17 at 08:23
  • Sorry, you are right. I missed the unique use of key. Thta is not a common use case. You may delete my two comments. – chmike Aug 27 '17 at 08:41