2
$\begingroup$

Would there be any benefit to symmetrically encrypting the IV and MAC in an AEAD mode of operation? More specifically would this prevent someone from exploiting the accidental use of a duplicate IV with the same key? Normally with most AEAD modes (and XOR-based stream ciphers) same IV + same key + different message = bad.

Example: let's say you have AES-GCM with a 64-bit IV and a 64-bit MAC / authentication tag. Now let's say after encrypting with AES-GCM you take the IV and MAC together and encrypt both with AES (using the same key or a derived key) in ECB mode (one 128-bit block) and send AES(IV|MAC) instead of sending the IV and MAC. Then at decrypt you AES decrypt that block and then run GCM with decryption and authentication check as usual.

If you duplicate an IV with a different message, the AES(IV|MAC) result will be different and since the IV and MAC are not visible in plaintext they can't be used by the attacker... right? (Obviously if both message and IV are identical the attacker can see that there was a duplicate of the same message, but that doesn't help them attack authentication for other messages.)

Other than costing a little bit of extra CPU does this help security? Am I missing something? This feels too simple to be novel.

$\endgroup$
3
  • $\begingroup$ "Other than costing a little bit of extra CPU does this help security?" No. $\endgroup$ Aug 15, 2019 at 23:43
  • $\begingroup$ Why not? The reply below explains the known plaintext attack against this scheme, but a 'no' with no explanation isn't that useful. $\endgroup$ Aug 16, 2019 at 3:37
  • 1
    $\begingroup$ You asked several questions, the answer to the one i referenced was either a hard no, or a yes with additional detail. The last question, "Am I missing something?", is what the answer below covers. In fact that answer does not adequately cover all the potential issues you may encounter, I will add another answer which should provide better explanation $\endgroup$ Aug 16, 2019 at 20:43

2 Answers 2

5
$\begingroup$

If a (nonce, key) is reused with two distinct messages A and B, an attacker can learn A⊕B = E(A)⊕E(B).

So, if either plaintext is known, the other one can be immediately decrypted.

This is why nonce-misuse resistant schemes require two passes: a first pass to compute a hash of the message, the second one to perform the actual encryption with an IV, and possibly a subkey derived from that hash.

$\endgroup$
5
  • $\begingroup$ Hmm... but wouldn't this result in just the compromise of the two colliding messages? Would other messages using the same key also be compromised? My thought was that hiding the actual nonce and MAC would protect against the attacker using a collision to attack other messages or forge different messages. I thought in the ordinary case (nonce/MAC in the clear) GCM was "sudden death" on nonce+key reuse, but maybe I'm mis-remembering that or confusing it with another algorithm. $\endgroup$ Aug 15, 2019 at 23:39
  • 1
    $\begingroup$ @AdamIerymenko If the attack that is described works in every case where the nonce is reused under the same key. Since this would mean that the key stream is the same for the two messages. $\endgroup$ Aug 16, 2019 at 17:40
  • 1
    $\begingroup$ Sending AES(IV,MAC) instead of IV,MAC in plaintext means you can't look for duplicate IVs by just looking at them. An attacker has to do something like XOR all messages with all other messages (n^n) and check randomness or look for known plaintext. That's orders of magnitude more CPU intensive. $\endgroup$ Aug 16, 2019 at 19:29
  • $\begingroup$ I guess you could AES-GCM and then AES-ECB the resulting IV, MAC, and ciphertext. Then you can't XOR messages and get anywhere. But that adds enough overhead that it's probably equivalent or slower than AES-GCM-SIV. $\endgroup$ Aug 16, 2019 at 19:32
  • 1
    $\begingroup$ As you say, it becomes a two-pass scheme. I think I get why a nonce misuse resistant scheme seems to have to be two-pass in one way or another. $\endgroup$ Aug 16, 2019 at 20:23
2
$\begingroup$

Would there be any benefit to symmetrically encrypting the IV and MAC in an AEAD mode of operation?

Not really. The MAC is already encrypted as part of GCM mode. Encrypting the IV just hides it, decryption of the message still requires the key.

More specifically would this prevent someone from exploiting the accidental use of a duplicate IV with the same key?

No, the person encrypting the message is the one that would duplicate the IV, the attacker does not necessarily need to know what the IV is to recover, they do not need to know the MAC either. There may be more work, but they dont have to attack the entire message, just a few bytes to see if something is off.

If you duplicate an IV with a different message, the AES(IV|MAC) result will be different and since the IV and MAC are not visible in plaintext they can't be used by the attacker... right?

Correct.. unless you do it wrong, then it can be much EASIER for the attacker, but once again since the attacker does not have the key, they are not likely to use these anyway for plaintext recovery. MAC forgery attacks are different, and an additional layer of encryption on the MAC may help thwart these.

Other than costing a little bit of extra CPU does this help security?

Hiding the IV may add security, but no more so than hiding the key to the message... which is done by default.

Am I missing something? This feels too simple to be novel.

Imagine how an attacker would go about attacking the ciphertext if they did not know the IV or MAC for any message, but they did know that you are using a modified mode specifically because there is a higher chance that you are reusing the IV. There are also schemes that are 1 pass which are nonce reuse resistant, some faster than others.

There are 2 solutions to the problem you are looking to address.
Don't reuse the nonce, there are many ways to guarantee uniqueness.
Use a different mode, there are many to choose from.

$\endgroup$

Your Answer

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

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