3
$\begingroup$

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?

$\endgroup$
3
  • $\begingroup$ Possible Dupe: crypto.stackexchange.com/a/58728/36960, but I feel it's not very authoritative and canonical. $\endgroup$
    – DannyNiu
    Commented Apr 4, 2023 at 4:06
  • 1
    $\begingroup$ 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. $\endgroup$ Commented Apr 4, 2023 at 11:16
  • 1
    $\begingroup$ 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 $\endgroup$
    – DannyNiu
    Commented Apr 4, 2023 at 12:47

1 Answer 1

3
$\begingroup$

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.

$\endgroup$
1
  • 1
    $\begingroup$ 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. $\endgroup$ Commented Apr 5, 2023 at 11:27

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.