3
$\begingroup$

I would like to minimize the encrypted packet size. Is it possible to derive the IV from a non-repeatable counter? For example, take a 32 bit counter, hash it with a key (different from the AES key), and then use the result as a 128 bit IV. The counter will increment on each packet, and not recycle during the lifetime of the key. Then I could send the 32 bit of the counter, instead of the whole 128 bit IV, and if the transmitter and receiver are in sync, then there is even no need to transmit the counter at all.

Is it a reasonable solution?

Improve this question
$\endgroup$
6
  • $\begingroup$ I guess this boils down to "Does a 32 bit counter provide sufficient entropy for an AES-CBC?". Great question! (NIST SP800-38a doesn't seem to mention this) $\endgroup$ Commented Oct 16, 2018 at 11:26
  • $\begingroup$ @MikeOunsworth Looks to me like the entropy would come from the "IV hashing key" (though of course HMAC would be better than a homemade keyed hash construction). I know the IV in TLS is implicit, but I don't remember exactly how it's done, that might be something to look at. $\endgroup$ Commented Oct 16, 2018 at 12:18
  • $\begingroup$ @AndrolGenhald That would depend how frequently the HMAC key is being changed, right? On first reading I assumed it was a static key, therefore not adding entropy from one IV to the next. $\endgroup$ Commented Oct 16, 2018 at 12:21
  • 1
    $\begingroup$ @AndrolGenhald Yeah, definitely a question for the crypto folks. If the goal is to be unpredictable then I agree with you, but I think that for IVs the goal is to never repeat an IV, in which case a 32-bit counter gives you 2^32 unique IVs, regardless of how you hash it. $\endgroup$ Commented Oct 16, 2018 at 12:36
  • 1
    $\begingroup$ @MikeOunsworth Sometimes they're used interchangeably, but I prefer to distinguish between a nonce (used in CTR mode) and an IV (used in CBC mode). Nonces must be used once, IVs must be both unpredictable and also used once. I think you can get an IV by HMACing a nonce (provided the HMAC key remains secret of course). With a 32 bit counter it might also be a good idea to make sure it fails rather than wrapping around and reusing IVs, just in case. $\endgroup$ Commented Oct 16, 2018 at 18:51

1 Answer 1

Reset to default
2
$\begingroup$

For CBC, the IV must be chosen uniformly at random¹. Furthermore the IV must be independent of the plaintext: if you start sending a message encrypted with CBC, and then an adversary can submit some plaintext that will go in a later part of the message, they may be able to decrypt the whole message.

The output of a cryptographic hash function isn't necessarily uniformly random, but it may be close enough. Your method is very close to encrypting a counter, which is considered safe. But you're still saddled with the downsides of CBC: you must not allow the adversary to inject message content after they've seen the IV, and you must be very careful with padding.

I recommend using CTR instead of CBC. CTR is a lot easier to use correctly. All you need is that the counter does not repeat ever. It doesn't need to be random or unpredictable. Just remember that the counter is incremented with each block, not with each message.

In addition, consider whether you need to authenticate the message. If you don't have a good reason why it isn't necessary, then you definitely need to authenticate the message. To encrypt and authenticate the message, use an authenticated encryption mode such as GCM or CCM. Most authenticated encryption modes use CTR for encryption, but they may have different constraints on the IV due to the way they use it (and the IV for the authenticated encryption mode is not always used directly as the initial counter value for CTR).

¹ Exception: if the key is only ever used once then the IV can be anything.

Improve this answer
$\endgroup$

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.