# Why must IV be sent with each packet?

I was reading about Encrypt-then-MAC and everywhere I go it seems people include the IV with the ciphertext generated for each message then MAC that and send all the information concatenated.

Why do I need to send the IV more than once?

-
You don't need to send "the IV" more than once. $\:$ On the other hand, you need to send and MAC each IV. $\;\;\;\;$ – Ricky Demer Apr 30 '14 at 14:47
Ah, that makes sense. Does the IV actually need to change in the lifetime of one session (assuming the session lasts at most an hour)? Well, I guess that's a relative question – user3100783 Apr 30 '14 at 14:48
The IV needs to change in the lifetime of one session so that an eavesdropper can't determine whether or not a plaintext was repeated. $\;$ – Ricky Demer Apr 30 '14 at 14:51
The IV must be different for each message. If you can use an implicit IV, such as a counter you don't need to send it explicitly. (At least with a mode that only needs unique IVs like CTR. For random IVs as in CBC you need some modifications, but in principle this is still possible) – CodesInChaos Apr 30 '14 at 15:19
You need a new IV for each message. You can't reuse the last block of the previous message. Doing that caused the BEAST attack against SSL. The assumption behind CBC's chaining is that an attacker can't see part of the ciphertext and then influence later plaintext. – CodesInChaos Apr 30 '14 at 17:17

I assume your protocol is message oriented. You needn't repeat the IV, but need to supply a new one for every message.

This can be either:

1. a random string from a CSPRNG,
2. a concatenation of a random string (sent once per session, if you're traffic-savvy) and a message counter (can be omitted from the packet, too), or
3. a member of any other unique sequence of 'reasonably random' block-sized blobs.

For CBC mode, the IVs should be sufficiently random, e.g. output from (2) may be hashed.

-
Depending on the mode that uses the IV, this may not be great advice. For example, using a counter as an IV (even if some of the counter bits are hidden) might not be a great idea if the initial plaintext blocks of adjacent packets have a good probability in differing only in their LSBits. – poncho Jun 11 '14 at 20:14
For CBC, I agree. – NekojiruSou Jun 11 '14 at 20:17
Yes, I meant CBC mode specifically -- somehow that didn't make it into the comment... – poncho Jun 11 '14 at 20:24