Security issues of a MAC-then-Encrypt-then-MAC approach?

Question

Encrypt-then-MAC does provide ciphertext integrity, but no plaintext integrity. With MAC-then-Encrypt it’s the other way around: Plaintext integrity but no ciphertext integrity.

What comes to mind is that it could make sense to use both to fix that “partially missing integrity” issue:

$$\tt …\ MAC_2(ENCRYPT(plaintext,MAC_1(plaintext)))$$

Trying to research if this would introduce more problems instead of solving them, I wasn’t able to find any useful papers that provide a security analysis of this approach. Also, I wasn’t able to find any papers discussing related schemes.

Ignoring potential speed impacts and focusing strictly on the security aspects… is there any obvious reason I’m not seeing why such a scheme should not be considered in the first place? Or do related references/papers exist and I was simply too inapt to find them? (If, what should I be looking for?)

---

^EDIT:
<sub>As some confusion was expressed in the comment area – please note that the above LaTeX merely represents a readable hint at what I’m talking about. It is not meant to describe a whole formula (which I assumed be clear due to the prepended “$…$” and the fact that there is no $key$ in the above LaTeX either). The reason to prefer posting a hint instead of a complete formula was simple: the complete formula renders/formats much less readable and could have confused some people – which I wanted to prevent. Obviously, “what is less confusing to some, is more confusing to others”. That’s something I honestly hadn’t anticipated… my bad. Here’s the whole thing: $$CypherText = IV || Encrypt(PlainText || MAC_1(PlainText, MacKey_1), IV, CipherKey) || \\ MAC_2(IV || Encrypt(PlainText || MAC_1(PlainText, MacKey_1), IV, CipherKey), MacKey_2)$$ Don’t even ask how this would look if I wouldn’t be using a _{tag… yet, it may help understand why I opted-in to posting a hint.}

Answer 1

Using a MAC on the plaintext may potentially leak information about the plaintext (MAC algorithms do not necessarily ensure confidentiality of the data they are applied to, although some MAC algorithms like HMAC seem pretty safe). If you want to avoid this (theoretical) problem, then you should encrypt the MAC on the plaintext (i.e. MAC-then-encrypt, not MAC-and-encrypt).

As long as you encrypt the inner MAC along with the plaintext, and the key for the inner MAC is unrelated to the key for encryption, then it is "obvious" that this inner MAC does not induce extra trouble; that inner MAC can be viewed as some plaintext redundancy. (In fact, you could replace the inner MAC with a simple hash function.)

Having two MAC algorithms still seems wasteful, in CPU and data size. If the problem you are trying to fix is a wrong decryption key in an encrypt-then-MAC setup, then a more efficient solution is to derive the encryption key and the MAC key from a single master key, using a KDF. If you do that, then, when the MAC matches, you know that you used the right MAC key, and, by property of the KDF, you also know that the encryption key is the right one. It so happens that deriving encryption and MAC key from a single source with a KDF is a very common situation; so the problem of "lack of plaintext integrity" does not happen in practice. This is why the construction with two MAC you are alluding to does not appear to be much studied.

Answer 2

Small addition:

You do not lose integrity when using encrypt-then-MAC. Since encryption is an injection, distinct plaintexts produce distinct ciphertexts, so plaintext forgery implies ciphertext forgery, which is hard if encrypt-then-MAC is secure.