Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Most of the time, when some data must be encrypted, it must also be protected with a MAC, because encryption protects only against passive attackers. There are some nifty encryption modes which include a MAC (EAX, GCM...) but let's assume that we are doing old-style crypto, so we have a standalone encryption method (e.g. AES with CBC chaining and PKCS#5 padding) and a standalone MAC (e.g. HMAC with SHA-256). How should we assemble the encryption and the MAC?

  • MAC-then-Encrypt: Compute the MAC on the cleartext, append it to the data, and then encrypt the whole? (That's what TLS does)
  • Encrypt-and-MAC: Compute the MAC on the cleartext, encrypt the cleartext, and then append the MAC at the end of the ciphertext?
  • Encrypt-then-MAC: Encrypt the cleartext, then compute the MAC on the ciphertext, and append it to the ciphertext? (In that case, we do not forget to include the initialization vector (IV) and the encryption method identifier into the MACed data.)

The first two options are often called "MAC-then-encrypt" while the third is "encrypt-then-MAC". What are the arguments for or against either?

share|improve this question
I've heard the second method most commonly referred to as encrypt-and-mac. – Stavros Korokithakis Oct 12 '13 at 14:35
I am a bit perplexed by the fact that this question seems highly related to…, but has diametrically opposed answers... – Clément Mar 24 '14 at 12:41
I haven't got time to write it up at the moment, but this forthcoming EuroCrypt paper is well worth a read – figlesquidge Apr 3 '14 at 9:31
@Clément: the confusion comes from the widespread (but wrong) habit of calling MAC "signatures". In fact MAC and signatures are very different things used in very different contexts. Sign-then-encrypt protocols also use a distinct encryption key for each message, which nullifies all padding oracle attacks; and the signature is meant to serve as proof (e.g. in a trial), so it MUST be applied on the plaintext message. In MAC+encrypt contexts, the same symmetric key is often reused, and there is no "proof" requirement. – Thomas Pornin Apr 3 '14 at 10:56
@Clément one difference is that here the secrets are shared, while in the public-key setting, anyone knowing the public key of the recipient can do the encryption part well. – npouillard Jul 2 '15 at 8:29

11 Answers 11

up vote 158 down vote accepted

I'm assuming you actually know all of this better than I do... anyway, this paper neatly summarises all these approaches and what level of security they do or don't provide. I shall paraphrase it in English, rather than Mathematical notation, as I understand it, here:

  • Encrypt-then-MAC:
    • Provides integrity of Ciphertext. Assuming the MAC shared secret has not been compromised, we ought to be able to deduce whether a given ciphertext is indeed authentic or has been forged; for example, in public key cryptography anyone can send you messages. EtM ensures you only read valid messages.
    • Plaintext integrity.
    • If the cipher scheme is malleable we need not be so concerned, since the MAC code will filter out this invalid ciphertext.
    • The MAC does not provide any information on the plaintext since, assuming the output of the cipher appears random, so does the MAC. In other words, we haven't carried any structure from the plaintext into the MAC code.
  • MAC-then-Encrypt:
    • Does not provide any integrity on the ciphertext, since we have no way of knowing until we decrypt the message whether it was indeed authentic or spoofed.
    • Plaintext integrity.
    • If the cipher scheme is malleable it may be possible to alter the message to appear valid and have a valid MAC code. This is a theoretical point, of course, since practically speaking the MAC secret should provide protection.
    • Here, the MAC cannot provide any information on the plaintext either, since it is encrypted.
  • Encrypt-and-MAC:
    • No integrity on the ciphertext again, since the MAC is taken against the plaintext. This opens the door to some chosen-ciphertext attacks on the cipher, as shown in section 4 of Breaking and provably repairing the SSH authenticated encryption scheme: A case study of the Encode-then-Encrypt-and-MAC paradigm.
    • Integrity of the plaintext can be verified
    • If the cipher scheme is malleable, the contents of the ciphertext could well be altered, but on decryption we ought to find the plaintext is invalid. Of course, any implementation error that can be exploited in the decryption process has been by that point.
    • May reveal information about the plaintext in the MAC. Theoretical, of course, but a less than ideal scenario. This occurs if the plaintext messages are repeated, and the MACed data does not include a counter (it does in the SSH 2 protocol, but only as a 32-bit counter, so you should take care to rekey before it overflows).

In short, Encrypt-then-MAC is the most ideal scenario. Any modifications to the ciphertext that do not also have a valid MAC code can be filtered out before decryption, protecting against any attacks on the implementation. The MAC cannot, also, be used to infer anything about the plaintext. MAC-then-Encrypt and Encrypt-and-MAC both provide different levels of security, but not the complete set provided by Encrypt-then-MAC.

share|improve this answer
Please also note the "padding oracle attack" in the answer from Thomas. – Maarten Bodewes Nov 29 '11 at 20:55
For personal/future reference: Encrypt-then-MAC = Encrypt the plaintext, MAC the ciphertext + iv then append it to the ciphertext. MAC-then-Encrypt = MAC the plaintext then append the MAC to the plaintext then Encrypt it all. Encrypt-and-MAC = Encrypt and MAC the plaintext then append the MAC onto the ciphertext. – MD Kieran Jun 25 '13 at 21:23
Could you perhaps comment on… ? It seems to be a closely related, but with diametrically opposed answers... – Clément Mar 24 '14 at 12:42
Great! I just find that the remarks there to be rather relevant (it I encrypt then MAC a message that says "add me to sudoers, the root password is 'blah'", and send it to my server, then an eavesdropper can resign the same encrypted message and get added as well...) – Clément Mar 24 '14 at 13:41
@Clément I have had a go at explaining the difference via a separate question, see - feel free to ask for clarification there :) – user46 Apr 9 '14 at 9:18

If you look at the paper "Tweakable Block Ciphers" by Moses Liskov, Ronald L. Rivest, and David Wagner published in Advances in Cryptology - Crypto 2002, Proceedings, 2442, section 4.3 Tweakable Authenticated Encryption (TAE), the MAC is computed over the plaintext, appended to the plaintext, and encrypted along with the plaintext. They then supply a proof of their Theorem 3 "If E is a secure tweakable block cipher, the E used in TAE mode will be unforgeable and pseudorandom".

share|improve this answer

@Ninefingers answers the question quite well; I just want to add a few details.

Encrypt-then-MAC is the mode which is recommended by most researchers. Mostly, it makes it easier to prove the security of the encryption part (because thanks to the MAC, a decryption engine cannot be fed with invalid ciphertexts; this yields automatic protection against chosen ciphertext attacks) and also avoids any trouble to confidentiality from the MAC (since the MAC operates on the encrypted text, it cannot reveal anything about the plaintext, regardless of its quality). Note that the padding oracle attacks, which have been applied in the field to ASP.NET, are chosen ciphertext attacks.

Ferguson and Schneier, in their book Practical Cryptography, have argued the opposite: that MAC-then-encrypt (or MAC-and-encrypt) is the "natural" order and that encrypt-then-MAC is overly complex. The sore point of encrypt-then-MAC is that you have to be careful about what you MAC: you must not forget the initialization vector, or (in case the protocol allows algorithm flexibility) the unambiguous identifier for the encryption algorithm; otherwise, the attacker could change either, inducing a plaintext alteration which would be undetected by the MAC. To prove their point, Ferguson and Schneier describe an attack over an instance of IPsec in which the encrypt-then-MAC was not done properly.

So while encrypt-then-MAC is theoretically better, it is also somewhat harder to get right.

share|improve this answer

In order to provide message integrity, a hash or message authentication function (MAC) is used. Sometimes, encryption and integrity are used together as (i) encrypt-then-MAC: provides ciphertext integrity, but no plaintext integrity, (ii) MAC-then-encrypt: provides plaintext integrity, but no ciphertext integrity, and (iii) encrypt-and-MAC: provides plaintext integrity, but no ciphertext integrity. Encrypt-then-MAC is the most secure mode, as any changes to the ciphertext can be filtered out before decryption using a valid MAC code, and this protects the messages against any modification attacks. However, a combination of encryption and MAC, such as Galois/Counter Mode (GCM): combines counter mode of encryption with Galois mode of authentication, or Counter with Cipher Block Chaining (CBC)-MAC (CCM): combines CBC-MAC with counter mode of encryption, is preferred due to the security strength.

share|improve this answer

Besides the security benefits of encrypt-then-MAC that many other answers have mentioned, there's a performance benefit. Checking the MAC first on the receiving end allows you to reject forged messages without doing the work to decrypt them. Bernstein mentions this in (in the section "Should the stream be independent of the plaintext?").

share|improve this answer

Although there are already many answers here, I wanted to strongly advocate AGAINST MAC-then-encrypt. I fully agree with Thomas' first half of the answer, but completely disagree with the second half. The ciphertext is the ENTIRE ciphertext (including IV etc.), and this is what must be MACed. This is granted.

However, if you MAC-then-encrypt in the straightforward way, then you are completely vulnerable to padding-oracle attacks. by the "straightforward way", what I mean is that you call the "decrypt" function, and afterwards the "mac verify". However, if you get an error in the decrypt function, then you return this straight away, as a padding error. You have now just got a full blown padding oracle attack and you are dead. You can now hack the API and give a single error message only, but the time it takes to return the error has to be the same, whether it's a MAC error or a padding error. If you think that this is easy, then look at the Lucky13 attack on SSL. It's really really really hard (and much harder than just MACing all of the ciphertext).

The argument by Schneier and Ferguson for MAC-then-encrypt has no formal basis at all. The definition of authenticated-encryption is met by encrypt-then-MAC and is NOT met by MAC-then-encrypt. Furthermore, most implementations of MAC-then-encrypt are actually completely vulnerable to padding oracle attacks and so are actually broken in practice. Don't do this!

Having said all of the above, my recommendation is to not use any of this. You should be using GCM or CCM today (GCM is much faster, so use it as long as you are sure that your IV won't repeat). A combined authenticated-encryption scheme, with a single API call, and now you won't get in trouble.

share|improve this answer

The really important thing is, not encrypt-and-mac. The other two, you can debate, but both are at least theoretically sound -- one might just practically be better than the other. Encrypt-and-MAC falls apart for a very simple reason, though: the MAC is not meant to keep the plaintext secret.

The MAC is based on the plaintext. Authentication is not designed to obscure the plaintext. A MAC, therefore, provides some information about the plaintext used to make it.

The not-quite-appropriate-but-easy-to-understand example is a checksum. If we have a nine digit number plaintext and a one digit checksum, and ship it with the first nine digits encrypted but the checksum not, the checksum is going to help me learn things about the first nine digits of plaintext. If I can somehow find out eight of the nine digits, I can use the checksum to find out what the last digit is. There might be a lot of other things I can do with that checksum that ruin the integrity of the first nine digits.

So, as a recap: do not use encrypt-and-mac. Otherwise, whatever, you're good.

share|improve this answer
"the MAC is not meant to preserve the integrity of the plaintext" would be just as good a reason to avoid MAC-then-encrypt too. $\;$ – Ricky Demer Dec 4 '14 at 4:13
No -- because the MAC and plaintext are both encrypted. Once you decrypt the ciphertext, you're not worried about the integrity anymore, you've decrypted it. – Daniel Dec 4 '14 at 4:15
... Yes we are, otherwise there would be no point to any of these constructions. $\;$ – Ricky Demer Dec 4 '14 at 4:53
What? Of course there is. You can't tell anything about the plain text until you decrypt it. You have perfect plaintext integrity, until the ciphertext is decrypted. Once you decrypt the ciphertext, you're not supposed to have plaintext integrity, you're supposed to be able to read it -- that's what decryption is. – Daniel Dec 6 '14 at 2:43
I suspect you meant "confidentiality". $\;$ – Ricky Demer Dec 6 '14 at 5:07

I think Encrypt-then-MAC does not deliver Plaintext integrity, but only ciphertext integrity. If the MAC over the ciphertext is OK but then we use the wrong key to decrypt (for whatever reason), then the recipient receives a plaintext that the sender did not send and did not vouch for. If this can happen, this is a violation of plaintext integrity.

So, Encrypt-then-MAC is only secure if you can somehow be sure that decryption won't use the wrong key, and that any other processing/decoding done to the ciphertext after checking the MAC is completely correct. This is a somewhat fragile aspect of Encrypt-then-MAC, and one reason why Ferguson and Schneier advocate against Encrypt-then-MAC.

share|improve this answer
I edited the answer to more clearly express the point Josef was trying to make. Personally, I think the answer is fine (I upvoted it). – D.W. Apr 5 '14 at 1:08
I'll respond below but this threat of using the wrong key to decrypt is really strange. If I verify the MAC using the wrong key then it will also be broken and rejected. Encrypt-then-MAC should certainly be used. – Yehuda Lindell Jul 1 '15 at 16:16

Moxie Marlinspike calls it in his article the doom principle:

if you have to perform any cryptographic operation before verifying the MAC on a message you’ve received, it will somehow inevitably lead to doom.

He also demonstrates two attacks which are possible because of trying to decrypt before checking the MAC.

To summarize: "Encrypt Then Authenticate" is the way to go.

share|improve this answer
As-is, I have a hard time finding reason to upvote this answer because your answer is close to a link-only answer. Can you elaborate a bit on what you are quoting? For example: can you explain “why” it is a problem to be able to decrypt a message before checking authentication, and why Moxie says it will “inevitably lead to doom” if you MAC-then-encrypt? That would certainly make your answer more valuable… after all, the question clearly asks “What are the arguments for or against either?” I can't really see you're providing arguments. Instead, you merely point to and quote a site. – e-sushi Apr 3 '14 at 10:49
@e-sushi Agreed - it remains that this is one of the best accessible treatment of the subject. – user2398029 Apr 8 '14 at 0:51
It is worth noting that this principle rules out applying the MAC to the plaintext regardless of whether the MAC is later encrypted or not. The principle itself is intuitively sound because the sooner you can discard a message with an invalid MAC, the less code can be targeted with corrupted inputs. One just has to not fall into the trap of assuming that just because the message carries a valid MAC, there is no way it could possibly be used to exploit buffer overflows or other vulnerabilities. – kasperd Aug 12 '14 at 20:21

Hugo Krawczyk has a paper titled The Order of Encryption and Authentication for Protecting Communications (or: How Secure Is SSL?). It identifies 3 types of combining authentication (MAC) with encryption:

  1. Encrypt then Authenticate (EtA) used in IPsec;
  2. Authenticate then Encrypt (AtE) used in SSL;
  3. Encrypt and Authenticate (E&A) used in SSH.

It proves that EtA is the secure way to use, and both AtE and E&A are subject to attacks, unless the encryption method is either in CBC mode or it is a stream cipher.

The abstract says everything; I emphasized important parts by bolding them:

We study the question of how to generically compose symmetric encryption and authentication when building “secure channels” for the protection of communications over insecure networks. We show that any secure channels protocol designed to work with any combination of secure encryption (against chosen plaintext attacks) and secure MAC must use the encrypt-then-authenticate method. We demonstrate this by showing that the other common methods of composing encryption and authentication, including the authenticate-then-encrypt method used in SSL, are not generically secure. We show an example of an encryption function that provides (Shannon’s) perfect secrecy but when combined with any MAC function under the authenticate-then-encrypt method yields a totally insecure protocol (for example, finding passwords or credit card numbers transmitted under the protection of such protocol becomes an easy task for an active attacker). The same applies to the encrypt-and-authenticate method used in SSH.

On the positive side we show that the authenticate-then-encrypt method is secure if the encryption method in use is either CBC mode (with an underlying secure block cipher) or a stream cipher (that xor the data with a random or pseudorandom pad). Thus, while we show the generic security of SSL to be broken, the current practical implementations of the protocol that use the above modes of encryption are safe.

share|improve this answer
CBC decrypt before authentication in an online prococol is secure? What about padding oracle attacks? Or do they explicitly specify that you need to verify the MAC in the last block before unpadding? – Maarten Bodewes Nov 29 '11 at 21:04
note that OpenSSH also supports E-t-M modes now (can be selected by limiting the hmacs): – eckes Jan 6 '15 at 17:00

There is no property of a MAC that states that information about the input should not be leaked. As such, you should encrypt the message first, then apply a MAC. This way, even if the MAC leaks information, all that is leaked is ciphertext.

share|improve this answer
Or MAC then Encrypt, so that the MAC can't leak information, because it can't be read by any attacker. – Daniel Dec 4 '14 at 4:09

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.