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

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:
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 <sub> tag… yet, it may help understand why I opted-in to posting a hint.

• Background: Should we MAC-then-encrypt or encrypt-then-MAC? Could you comment on why or when one would want plaintext integrity in a way that isn't satisfied by ciphertext integrity? – Gilles 'SO- stop being evil' Aug 12 '14 at 15:47
• @Gilles One of the answers to the question you’ve linked to provides a hint. For somewhat alike reasons Ferguson and Schneier also argue in favor of MAC-then-encrypt. I think that should answer your question. – e-sushi Aug 12 '14 at 15:52
• I don't think "plaintext integrity" is useful in the context of of MACs since a mismatch between MAC and cipher key can only happen if you messed up your protocol. I'd only use a similar approach if the inner authentication is a signature, not a MAC. – CodesInChaos Aug 12 '14 at 16:25
• In the scheme proposed in the question, are you saying the ciphertext is concatenated to the derived MAC(E(MAC())) value? So you're deriving an alternative HMAC. – Jeff-Inventor ChromeOS Aug 13 '14 at 1:49
• @Jeff-InventorChromeOS Nope… the fact that I posted a hint instead of a full-fledged formula seems to confuse some people. To avoid such confusion, I added an explaining edit. Hope that helps… – e-sushi Aug 13 '14 at 17:01