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?)

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.

  • 2
    $\begingroup$ 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? $\endgroup$ Aug 12, 2014 at 15:47
  • 1
    $\begingroup$ @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. $\endgroup$
    – e-sushi
    Aug 12, 2014 at 15:52
  • 3
    $\begingroup$ 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. $\endgroup$ Aug 12, 2014 at 16:25
  • $\begingroup$ 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. $\endgroup$ Aug 13, 2014 at 1:49
  • $\begingroup$ @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… $\endgroup$
    – e-sushi
    Aug 13, 2014 at 17:01

2 Answers 2


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.


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.

  • $\begingroup$ Distinct plaintexts produce distinct ciphertexts for a given key. Encrypt-then-Mac doesn't provide integrity if an attacker can trick you into decrypting with an arbitrary key. $\endgroup$
    – Fax
    Feb 12, 2019 at 19:51

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.