Why in authenticated encryptions do we need separate keys for cipher and MAC?

vu flag

As asked, I suppose this must have been answered before, even if not in the form asked here. The most notable AEAD schemes GCM-AES and ChaCha20-Poly1305 do this. Also, even outside AEAD, ad-hoc constructs such as CBC+HMAC also require separate keys. So:

Q1: Why use separate keys in authenticated encryption? As in

  1. what security hole does it avoid,
  2. what heuristic benefit (non-security or not-strictly-security, and performance/efficiency) does it bring?

Q2: What're the real-world cases where a system gets hacked for not using separate keys for cipher and MAC?

DannyNiu avatar
vu flag
Possible Dupe:, but I feel it's not very authoritative and canonical.
samuel-lucas6 avatar
bs flag
I think that linked answer is quite good. In reality, a single key for encryption and hashing/HMAC is fine. It's actually begun to be recommended in the case of things like the [CTX construction]( for AEAD commitment because it's of course cheaper than deriving separate keys. However, deriving a separate MAC key is actually an efficient way of authenticating the nonce and associated data in an Encrypt-then-MAC scheme with a hash-based MAC like [this](
DannyNiu avatar
vu flag
So It's a false premise then. Maybe I should be asking about the rationale of using separate keys in algorithm design. Re-tagged. @samuel-lucas6
ng flag

TL;DR: One usage, one key.

Why use separate keys in authenticated encryption?

Because the security proof of the encryption on one hand, of the authentication on the other hand, assume that their respective key is not used elsewhere.

What's the real-world cases where a system gets hacked for not using separate keys for cipher and MAC?

Assume plaintext (always one block of 16 bytes) is encrypted with AES-CBC using confidentiality key $K_C$, and then is MAC-ed (including Initialization Vector) with plain AES-CBC-MAC using integrity key $K_A$.

This is a textbook encrypt-then-MAC. If $K_C$ and $K_A$ are random unrelated secrets, and AES is a secure block cipher, and there is no side-channel, this is demonstrably secure under Chosen Plaintext Attack, and also Chosen Ciphertext Attack. But if $K_C=K_A$, then an adversary can make a forgery under mere Known Plaintext Attack (thus also under CPA).

If we detail the cryptosystem as designed:

  • The sender of plaintext block $P$
    • draws random Initialization Vector $\mathsf{IV}$,
    • computes ciphertext $C\gets E_{K_C}(\mathsf{IV}\oplus P)$,
    • computes authenticator $A\gets E_{K_A}(E_{K_A}(\mathsf{IV})\oplus C)$,
    • sends $(\mathsf{IV},C,A)$.
  • The receiver of alleged $(\mathsf{IV},C,A)$
    • accepts the message if $E_{K_A}(E_{K_A}(\mathsf{IV})\oplus C)=A$,
    • and in the affirmative deciphers per $P\gets D_{K_C}(C)\oplus\mathsf{IV}$.

Attack with $K_C=K_A$ goes:

  • Intercept one message $(\mathsf{IV}_0, C_0, A_0)$
  • Obtain the corresponding plaintext $P_0$ e.g. because it's no longer deemed secret after a while.
  • Compute $\mathsf{IV}_1\gets\mathsf{IV}_0\oplus P_0$
  • Compute $C_1\gets\mathsf{IV}_0\oplus P_0\oplus C_0$
  • Set $A_1\gets C_0$
  • Submit $(\mathsf{IV}_1, C_1, A_1)$ to the receiver.
  • Receiver accepts the message because
    • It checks $E_{K_A}(E_{K_A}(\mathsf{IV_1})\oplus C_1)=A_1$,
    • that is $E_{K_A}(E_{K_A}(\mathsf{IV}_0\oplus P_0)\oplus\mathsf{IV}_0\oplus P_0\oplus C_0)=C_0$.
    • Since $K_C=K_A$, that's checking $E_{K_C}(E_{K_C}(\mathsf{IV}_0\oplus P_0)\oplus\mathsf{IV}_0\oplus P_0\oplus C_0)=C_0$.
    • Per the first encryption, $E_{K_C}(\mathsf{IV}_0\oplus P_0)=C_0$.
    • Thus the test is $E_{K_C}(C_0\oplus \mathsf{IV}_0\oplus P_0\oplus C_0)=C_0$,
    • that is $E_{K_C}(\mathsf{IV}_0\oplus P_0)=C_0$, which holds!
  • Receiver deciphers per $P_1\gets D_{K_C}(C_1)\oplus\mathsf{IV_1}$ which is $D_{K_C}(\mathsf{IV}_0\oplus P_0\oplus C_0)\oplus\mathsf{IV}_0\oplus P_0$, which has no reason to be $P_0$, and thus was not authenticated (only $P_0$ was).

We can easily adapt the attack to every common block cipher mode of operation, e.g. AES-CTR. The root of the problem is reusing the same block cipher and key for encryption and authentication. We wouldn't have this issue if authentication was with an unrelated algorithm, e.g. HMAC-SHA-256.

samuel-lucas6 avatar
bs flag
It may be worth mentioning that Poly1305 [requires]( a unique key as well, whereas the AEAD encryption key is allowed to be reused with different nonces.
I sit in a Tesla and translated this thread with Ai:


Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.