Is it OK to use a secret IV as key when creating keyed MD5 checksum for fixed-size data?

Is it OK to use a secret IV as key when creating keyed MD5 checksum for fixed-size data?

Because data size is known, attacker cannot append anything. And I think it's hard to raise chosen-plaintext attack if the secret is well kept, but I’ld like to be sure.

• Assuming you choose the IV uniformly, this should have the same security properties as md5(key|m) with key padded to a full block. That construction suffers from length extension attacks, which don't apply for fixed data size. But why use this over HMAC? Nov 18 '15 at 15:50

So the idea is to use the IV of MD5 as a key to create a MAC. Like CodesInChaos mentions in a comment, it would be pretty much equivalent to using $H(k||m)$, if your IV is randomly chosen.

By only using it on fixed length messages you avoid the length extension attack, but that is not the only attack on hash constructions that try to create a MAC. In this question on $H(k||m||k)$ the answer provides links to an attack that uses internal collisions (pdf, Proposition 4):

This means that an attacker can replace or delete $w \le s$ trailing blocks, and that the attack is applicable even if the input is of fixed length [...]

It can also be applied here. So, no, it would not be secure. At least strictly speaking: the attack requires seeing $2^{n/2}$ authenticated messages, though a smaller amount could allow an attack with some probability.

You should use HMAC or another standard MAC instead. I would also consider a more secure hash than MD5, if you use a hash based MAC, even though the attacks known for MD5 are not sufficient to break HMAC.

An IV is not a key.

In modes of operation, an IV does not have to be kept secret, and in order to decrypt everything you need the IV, which is transmitted in the clear.

The only required property of an IV is that it is unique, or at least with overwhelming probability unique. For that you can use "bad" randomness to create it (e.g. from a non-secure PRNG). In fact for a lengthy protocol with several rounds and IVs, it would be fine to start at a random number and then just increase it by 1 every time. Basically, it is not a problem if the IV is predictable, as long as the same one is not used more than once (with almost certain probability).

A key requires good entropy, and should always be generated by a CSPRNG or a similar construction (e.g. a KDF). If you can predict it from previous output of your RNG, of previously used IVs, etc, ... you have a serious problem.

But in the end: Why create something which already exists and is examined broadly? There are quite a few schemes for message authentication codes (that's what you mean), including HMAC with MD5. However, for the design of current systems you should not use MD5. Even if it is still considered secure to be used in HMAC, MD5 itself is flawed and should only be used in the context of legacy systems.

• "The only required property of an IV is that it is unique". This is wrong. For CBC, the IV must be unpredictable (to an attacker). The IV must normally also be of a certain size or in a certain range. The IV properties therefore depend on mode, algorithm and maybe even configuration. Nov 18 '15 at 18:18