Is a static IV really less secure than an IV generated from a master key?

Question

As an example, let's take a simple situation where AES-256-CBC with IV + MAC is used to encrypt a given plainText and offer authentication.

iv.mac1.cipherText(plainText)

The keys are derived using HMAC for simplicity (alternatively could be HKDF)

masterkey = [32 random bytes];
encryptionKey = hmac_sha256(masterkey,'encryption_key');
mac = hmac_sha256(masterkey,'mac_key');
iv = hmac_sha256(masterkey,'iv_key');

Alternatively in a second solution the IV is defined in the codebase:

masterkey = [32 random bytes];
encryptionKey = hmac_sha256(masterkey,'encryption_key');
mac = hmac_sha256(masterkey,'mac_key');
iv = [32 hard coded bytes];

In both scenario's the IV itself is not stored or transmitted, and the masterkey is used to decrypt messages.

Is the static IV really less secure, given that deriving a key for the IV with the same masterkey also produces the same output?

Answer 1

This has been answered before, but I don't have enough reputation to comment yet, so I will just summarise and give my take.

Is it secure?

With a unique 256-bit key per message, you can technically get away with a fixed IV. However, with a unique 128-bit key, it's more risky because an attacker will get an advantage if they collect lots of ciphertexts encrypted under different keys.

If you don't use a unique key for each message, encrypting two plaintexts with the same initial block will cause them to have the same initial ciphertext block. It may sound unlikely that two messages would start the same, but it does happen. You want to avoid leaking this information as it has led to attacks.

Recommendations

The IV, which is 16 bytes rather than 32, is meant to be unique and unpredictable. Thus, it would be safest to use a random IV. Deriving the IV using a KDF also works, but you could theoretically end up deriving the same IV accidentally (e.g. using no salt but the same input keying material/master key). You can also encrypt a counter, although I wouldn't recommend that over the other options.

Importantly, with Encrypt-then-MAC, if you're not deriving the IV using a KDF (e.g. it's randomly generated), you must authenticate the IV (e.g. HMAC-SHA256(message: IV || ciphertext, key: macKey)).

The real question is why have you opted for AES-CBC? Encrypt-then-MAC has its advantages over current AEADs. However, I think many would argue AES-CTR is preferable (e.g. it supports counter nonces easily and is used within AES-GCM). I would personally recommend ChaCha20 though (XChaCha20 if you want random nonces), mainly because it has a higher security margin than AES whilst being frequently used, unlike Serpent, Twofish, and Threefish.