# Is it safe to "compress" an IV in AES256-CTR? [closed]

Alice is using AES256 in CTR mode to send encrypted messages to Bob. The messages are 4 byte values. Along with each encrypted message, Alice sends along a random 16 byte IV. f maps a 4 byte value v to the 16 byte values v|v|v|v (concatenates it with itself 4 times). Would it be secure for Alice to randomly generate 4 bytes s, encrypt her message using IV = f(s) and send Bob the encrypted message along with s (assuming Bob uses the same f to recompute the IV on his end)?

• Hint: assume $k$ plaintexts are encrypted, and compute the probability that knowledge of one plaintext allows to decipher that much of another one.
– fgrieu
Jun 21 at 8:11
• I'm not sure if I'm understanding your hint correctly, are you getting at the fact that this scheme tremendously increases the risk of IV collisions? Jun 21 at 8:33
• I guess it would depend on the injective function and the size of the messages. If this is a question I would suggest that information is missing. If I had to answer my answer would start with "No, not necessarily". Jun 21 at 8:40
• @MaartenBodewes I've added a concrete example for such a function and information about the messages. Is there any other information you believe this question is missing I should add? Jun 21 at 8:48
• As this is obviously homework, it is expected you to share your thoughts and directions so far. Jun 21 at 8:57

Brute force doesn't come into play; an IV is considered public knowledge. An attacker could try and let you encrypt additional messages to force an integer overflow within the encoded counter though.

The counter block of counter (CTR) mode generally consists of a nonce part for the separate messages and a counter part, for each (partial) block within the message. Other fields are of course possible, e.g. it is possible to have a "label" for different kind of usages of counter mode in a protocol (sending / receiving etc.).

For all blocks in all of the messages the counter block should be unique. As the counter generally starts at zero - something I would advice - this means that the nonce should be unique for each message.

Now in your scheme you would go from a 32 bit nonce to a 128 bit nonce by simply concatenating the data. This means that the domain of possible nonces is precisely as large as you started with. The counter however doesn't start at zero, which could form a problem as it is unclear what happens if it would overflow.

As the counter block is generally considered a 128-bit unsigned, big endian value by implementations. That means that you would have as much security if you would use VVVVVVVV | 00000000 | 00000000 | 00000000 where each V / 0 character represents a 8 bit byte. You could then encode messages up to $$2^{96}$$ blocks.

If course, this could be problematic as you would have a high collision chance if VVVVVVVV is generated randomly. I'll leave it up to you to calculate that. If the VVVVVVVV itself represents a message counter, well, calculating the maximum number of messages should be self evident.

In the end your function $$f$$ is fully redundant: it doesn't offer any additional security; it only provides unnecessary complexity.