0
$\begingroup$

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?

$\endgroup$
2
  • 1
    $\begingroup$ Would you be using the same master key to encrypt multiple messages? $\endgroup$
    – poncho
    Jul 5, 2022 at 14:42
  • $\begingroup$ In both scenario's a new master key will be generated each time for my particular use case. $\endgroup$ Jul 5, 2022 at 14:44

1 Answer 1

2
$\begingroup$

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.

$\endgroup$
3
  • $\begingroup$ Thank you for providing the link: "There's no imperious need for an IV when unique keys are used. Given that a 256-bit key cipher is used, what's proposed is safe." $\endgroup$ Jul 5, 2022 at 18:51
  • $\begingroup$ Still the link also contains another answer "You should use random IV even when unique keys are used. This prevents key-collision attack where the attacker collects number of cryptograms that have been encrypted with unique keys and brute-forces for key. Using predictable IV will reduce security of your cryptosystem by a factor of N (where N is the number of ciphertexts created). The attack recovers one of the ciphertext (but the attacker cannot control which one)." $\endgroup$ Jul 5, 2022 at 19:02
  • 1
    $\begingroup$ @swordsecurity I tried to address that in my answer. With a 256-bit key, that's not really a concern. $\endgroup$ Jul 5, 2022 at 19:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.