What is the advantage of Encrypt-then-MAC over Encrypt & MAC separately the plaintext [duplicate]

Question

For secrecy, authentication & integrity, you can either use

1. CipherText = Encrypt(PlainText)
   Signature = Hash(PlainText)

2. CipherText = Encrypt(PlainText)
   Signature = Hash(CipherText)

Either case, you send both CipherText & Signature to the receiver.

What is the advantage of one method over the other? Does it differ in case of Symmetric vs Asymmetric Encryption?

Answer 1

I'll be assuming the question means Message Authentication Code (MAC) where it uses "Signature" and "Hash". MAC, signature and hash are three different things: MAC uses a secret for generation and verification, signature uses a secret for generation only, hash uses no secret.

---

Following comment, and most important: sending in clear a MAC of the plaintext, as in "encrypt and MAC separately" sending $\operatorname{ENC}(M)\mathbin\|\operatorname{MAC}(M)\,$, without any further specification about the MAC, would be very poor practice: depending on the MAC, that can leak some information about the message $M$. In particular, for any deterministic MAC (as HMAC is) and a fixed key, identical messages will lead to identical MACs, and are thus trivially detected, breaking IND-CPA security.

---

The other historically used argument for encrypt-then-MAC (against MAC-then-encrypt) is that the seemingly natural corresponding procedure on the receive side is verify-MAC-then-decrypt, implying that decryption will only be carried on ciphertext that passed an integrity test. The adversary thus can not observe use of the decryption key on ciphertext that it chooses arbitrarily, since that ciphertext won't pass the MAC test and won't be decrypted. This in turn blocks a number of attacks that submit artificial or altered ciphertext to a decryption device, and use it's observed behavior to deduce useful information, or induce some desired behavior.

One example of vulnerable decrypt-then-verify-MAC would be an implementation where decryption is followed by a padding check, insuring that the last 16-byte block of ciphertext ends with 0 to 15 byte(s) at 0x00, then (walking back) a byte at 0x80; and if not aborts the use of the received ciphertext, only performing the MAC check if it does. By observing the timing of the decryption device, an adversary could then determine if the padding check fails or succeeds. For block encryption in CBC mode, iterating that apparently minor information leak allows decryption.

Other examples can be made, including side-channel attacks by differential power analysis of the decryption, when limited valid ciphertext is available to the attacker.

---

One serious problem with this historical argument for encrypt-then-MAC is that it is technically valid only if there is verify-MAC-then-decrypt on the receiver side. However, it is entirely possible to run decryption and MAC verification concurrently even for ciphertext produced with encrypt-then-MAC. And such concurrency is highly desirable, for it avoids scanning the ciphertext twice, which typically would have an impact on performance, at worse would make using crypto impractical.

Also, by integrating integrity check with encryption, it is possible to get the integrity part at sizably lower computational cost than that of a MAC. For these reasons, state of the art is authenticated encryption, such as AES-GCM-SIV. Thus in modern practice we do not encrypt-then-MAC, and even more seldom verify-MAC-then-decrypt, making this historical argument pointless. Authenticated encryption does secrecy, authentication & integrity in one primitive, no necessarily with a separate generic MAC.