Stack Overflow's 2025 Annual Developer Survey is still open — take the Survey before it closes

Should we MAC-then-encrypt or encrypt-then-MAC?

Asked 13 years, 11 months ago Modified 1 year, 1 month ago Viewed 202k times

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
429 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? (That's what SSH does)
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?
encryption protocol-design mac authenticated-encryption

Share Improve this question Follow edited Oct 7, 2021 at 6:47 asked Jul 19, 2011 at 21:39
Community Bot Thomas Pornin
1 88.3k 16 246
315
By clicking “Accept all cookies”, you agree Stack Exchange
can store cookies on your device and disclose information in
accordance with our Cookie Policy.
5 I've heard the second method most commonly referred to as encrypt-and-mac.
– Stavros Korokithakis OctNecessary
Accept all cookies
12, 2013 atcookies
14:35only
13 I am a bit perplexed by the fact that this question seems highly related to
crypto.stackexchange.com/questions/5458/… , but has diametrically opposed answers... – Clément
Mar 24, 2014 at 12:41
Customize settings
 23 @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, 2014 at 10:56
3 @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, 2015 at
8:29
13 Moxie Marlinspike says, 'When it comes to designing secure protocols, I have a principle that goes
like this: 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'. See moxie.org/blog/the-cryptographic-
doom-principle – mti2935 Dec 20, 2017 at 18:01

13 Answers Sorted by: Highest score (default)

I'm assuming you actually know all of this better than I do. Anyway, this paper neatly
summarizes all these approaches, and what level of security they do or don't provide. I shall
354 paraphrase it in English, rather than Mathematical notation, as I understand it.
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 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.
MAC-then-Encrypt:
Does not provide any integrity on the ciphertext, since we have no way of knowing
untilonweyourdecrypt
can store cookies device the messageinformation
and disclose whetherinit was indeed authentic or spoofed.
By clicking “Accept all cookies”, you agree Stack Exchange

Plaintext integrity.
accordance with our Cookie Policy.

If the cipher scheme is malleable it may be possible to alter the message to appear
valid and have a valid MAC. 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.
The 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 re-key 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 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 Follow edited Feb 2, 2022 at 19:28 answered Jul 19, 2011 at 23:07
j02 user46
5 3
7 Please also note the "padding oracle attack" in the answer from Thomas. – Maarten Bodewes ♦ Nov
29, 2011 at 20:55
50 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, 2013 at 21:23
7 Could you perhaps comment on crypto.stackexchange.com/questions/5458/… ? It seems to be a
closely related, but with diametrically opposed answers... – Clément Mar 24, 2014 at 12:42
2 @clement it is a good point although I don't think you'd use a mac for identity verification... but there
are definitely those who disagree that encrypt-then-mac is the best solution and their arguments are
By clicking “Accept all cookies”, you agree Stack Exchange

very very valid too. – user46 Mar 30, 2014 at 19:21

can store cookies on your device and disclose information in
accordance with our Cookie Policy.
3 @Clément I have had a go at explaining the difference via a separate question, see
crypto.stackexchange.com/q/15485/46 - feel free to ask for clarification there :) – user46 Apr 9,
2014 at 9:18

Some additional details to the accepted answer.

 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
158 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 Follow edited Oct 8, 2021 at 10:59 answered Jul 21, 2011 at 13:16
Maarten Bodewes ♦ Thomas Pornin
96.2k 14 169 88.3k 16 246
323 315
1 It really depends on the priorities of your application, though :) Whenever authentication is the key
point, use AtE, and whenever secrecy is paramount, use EtA :) I.e. whenever it's mostly about safety
and security, go for AtE, and whenever it's mostly about secrecy and security, go for EtA :) – yeoman
Oct 30, 2016 at 20:31
2 And never ever even consider using the same key for A & E 😬 – yeoman Oct 30, 2016 at 20:51
1 "you must not forget the initialization vector, or ... the unambiguous identifier for the encryption
algorithm" -- while implementing, it occurred to me that one has to be mindful as to how to do this:
the combined binary string has to be unique (i.e. the mapping injective)! Plain concatenation of binary
strings may not have this property if more than one component is of variable length. I opted for ASN-
DER. – Raphael Jul 13, 2017 at 15:05
5 So to sum it all, the zeroday paranoids will do mac-encrypt-mac. Or even encrypt-mac-encrypt-
mac. – Pacerier Oct 24, 2017 at 8:37
3 Also, Schneier et al. mention the Horton Principle... you can MAC your ciphertext but nobody can
By clicking “Accept all cookies”, you agree Stack Exchange

assure that it will be decrypted with the correct key, or that the original message as it was exactly
can store cookies on your device and disclose information in

produced is what is obtained after decryption – user1156544 Apr 19, 2019 at 21:47
accordance with our Cookie Policy.

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
57 (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 Follow edited Oct 7, 2021 at 6:47 answered Aug 10, 2011 at 11:03
Community Bot Sadeq Dousti
1 1,073 9 20
2 CBC decrypt before authentication in an online prococol is secure? What about padding oracle
attacks? Oralldocookies”,
they explicitly specify thatExchange
you need to verify the MAC in the last block before
By clicking
can store
“Accept
unpadding?
cookies on–your Maarten
device
you agree
Bodewes ♦ Novinformation
Stack
and disclose 29, 2011 atin 21:04
9 note that OpenSSH also supports E-t-M modes now (can be selected by limiting the hmacs):
accordance with our Cookie Policy.

stribika.github.io/2015/01/04/secure-secure-shell.html – eckes Jan 6, 2015 at 17:00

This list is not exhaustive though, there are cipher modes that provide authenticated encryption, i.e.
with no need for a separate hash algorittm (e.g. Galois/Counter Mode). I came up with several own
schemes but this is still early experimentation. One of them e.g. is called multi-pass CBC (which
cyclically applies CBC several times between standard cipher rounds), which appears to resist not
 only attacks on same-key CBC-MAC but also padding oracle attacks, but is impractical for large
messages. It will be a while before (and if) I publish. – Arne Vogel Jun 20, 2019 at 14:56
@ArneVogel: Sure there are other possibilities. Yet the OP is asking about the order of combing
encryption and MAC. – Sadeq Dousti Jun 21, 2019 at 11:07

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
51 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 Follow answered Jul 1, 2015 at 16:24
Yehuda Lindell
28.3k 1 68 86
2 You advocate against MAC-then-encrypt, and then recommend using CCM, which is exactly a MAC-
By clicking “Accept all cookies”, you agree Stack Exchange

then-encrypt scheme. Isn't it a contradiction? – Penghe Geng Sep 26, 2016 at 17:08
can store cookies on your device and disclose information in
accordance with our Cookie Policy.
8 CCM is a mode of encryption with a stand-alone proof of security and this distinguishes it from MAC-
then-encrypt. It should not have the pitfalls of MAC-then-encrypt. The only problem that can arise is
a bad implementation. I am certainly willing to concede that there is more chance of a bad
implementation in a mode like this, but then again everything can be badly implemented so I'm not
sure it should be a factor. – Yehuda Lindell Sep 27, 2016 at 0:08
1 IV related question: If a mode that does not use IV (like CTR) is used, should "nonce" be used in MAC
computation somehow or it will be computed only from plain text in this case? – Jolinar Aug 11, 2018
 at 11:53
2 The counter or IV must be included in the MAC. It is part of the ciphertext. – Yehuda Lindell Aug 12,
2018 at 3:31
And if the IV/nonce is derived from a salt (and password using KDF), what should be the part of MAC?
The salt, the derived IV, both, or it doesn't matter? Thanks – Jolinar Aug 12, 2018 at 20:11

Moxie Marlinspike calls it in his article https://moxie.org/2011/12/13/the-cryptographic-doom-

principle.html the doom principle:
25
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 Follow edited Apr 27, 2024 at 6:47 answered Apr 3, 2014 at 6:13
Community Bot Mouk
1 359 3 3
9 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, 2014 at 10:49
@e-sushi Agreed - it remains that this is one of the best accessible treatment of the subject.
– user2398029 Apr 8, 2014 at 0:51
1 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,
2014 at 20:21
By clicking “Accept all cookies”, you agree Stack Exchange
can store cookies on your device and disclose information in
1 Updated
accordance linkCookie
with our -- moxie.org/2011/12/13/the-cryptographic-doom-principle.html
Policy. – Eddie Feb 5, 2021 at
19:23

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
13 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 Follow edited Apr 4, 2014 at 16:27 answered Jul 31, 2013 at 14:37
D.W. Josef Schuler
37k 13 107 196 149 1 2
3 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, 2014 at 1:08
9 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, 2015 at 16:16
1 @YehudaLindell, The safest for the paranoid is still mac-encrypt-mac – Pacerier Oct 24, 2017 at 8:07

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-
9 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.
By clicking “Accept all cookies”, you agree Stack Exchange
can store cookies on your device and disclose information in
Share Improve this answer Follow
accordance with our Cookie Policy. edited Dec 6, 2014 at 5:11 answered Dec 4, 2014 at 4:08
Daniel
231 2 6
1 "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. – user991 Dec 4, 2014 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, 2014 at 4:15
1 ... Yes we are, otherwise there would be no point to any of these constructions. – user991 Dec 4,
2014 at 4:53
2 I suspect you meant "confidentiality". – user991 Dec 6, 2014 at 5:07
1 @Pacerier -- if you're doing it right, yes. "Encrypt-and-mac" refers to the stupid strategy of
encrypting the plaintext, mac'ing the plaintext, and then putting the plaintext mac at the end of the
ciphertext. – Daniel Nov 3, 2017 at 17:59

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
7 MAC leaks information, all that is leaked is ciphertext.
Share Improve this answer Follow answered Jul 20, 2011 at 11:38
foobarfuzzbizz
3,256 3 24 25

5 Or MAC then Encrypt, so that the MAC can't leak information, because it can't be read by any
attacker. – Daniel Dec 4, 2014 at 4:09
@Daniel, So how do you address the DOOM principle by Moxie? – Pacerier Oct 24, 2017 at 8:11

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
7 reject forged messages without doing the work to decrypt them. Bernstein mentions this in
http://cr.yp.to/snuffle/design.pdf (in the section "Should the stream be independent of the
plaintext?").
Share Improve this answer Follow answered Dec 26, 2015 at 18:31
Jack O'Connor
647 6 13
1 That's such a tiny performance boost, given the vast, vast majority messages will be correct
By clicking “Accept all cookies”, you agree Stack Exchange
messages and will go through two steps anyway, that this benefit can be all but ignored, IMHO.
can store cookies on your device and disclose information in
– Penghe Geng Sep 26, 2016 at 17:14
accordance with our Cookie Policy.

2 @xiaobai I think the idea is that it makes it (slightly) harder for an attacker to DOS you in some (niche)
situations. In a DOS attack, all of the packets flooding your server might be failing to authenticate,
and the rate at which your server could drop them might matter. – Jack O'Connor Sep 28, 2016 at
3:53
 1 Just note that "performance benefit" is not going to be any relevant if encrypt-mac itself was
insecure. – Pacerier Oct 24, 2017 at 8:41

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,
4 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 Follow answered Mar 24, 2016 at 13:00
TomS
61 1

In order to provide message integrity, a hash or message authentication function (MAC) is

used. Sometimes, encryption and integrity are used together as:
2 1. Encrypt-then-MAC: provides ciphertext integrity, but no plaintext integrity,
2. MAC-then-encrypt: provides plaintext integrity, but no ciphertext integrity, and
3. 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 the counter
mode of encryption, is preferred due to the security strength.
Share Improve this answer Follow edited Dec 26, 2017 at 4:05 answered Feb 5, 2016 at 16:22
Squeamish Ossifrage user24094
49.8k 3 121 230 145 7
3 Re "but no plaintext integrity", doesn't ciphertext integrity asserts plaintext integrity? – Pacerier Oct
24, “Accept
By clicking 2017 at all8:45
cookies”, you agree Stack Exchange
can store cookies on your device and disclose information in
accordance with our Cookie Policy.

Reading all of this leads me thinking that the best solution would be:
1 MAC-then-Encrypt-then-MAC
Bringing both guarranty on the plain text and cyphertext.
 I fully agree both are important :
MAC-then-Encrypt if your plain text is not structured and do not permit to confirm its
integrity without a MAC
Encrypt-then-MAC for the reasons provided in other answers, especially to avoid
decrypting bad data
Share Improve this answer Follow answered Feb 8, 2019 at 16:23
lalebarde
217 1 2 6
This looks conclusive. If it's not recommended, it would be fine to know, why. – rundekugel Nov 23,
2020 at 15:47

In many applications, only part of the data ( ) is encrypted, and some so-called Additional
m
Authenticated Data (AAD, usually some header data including nonce) is only authenticated
a

-1 but not encrypted.

Here is my argument: When AAD is used, Authentication-then-Encryption provides an
additional layer of protection for AAD than Encryption-then-Authentication, thus one
may argue it could be more secure in certain usages.
When AAD is used, if we use Encryption-then-Authentication, we will get:
a

E(m) + A(a + E(m))

for scheme, which means we encrypt first, and then concatenate it with a, and then encrypt
m
the result. Notice how is only protected by one layer of cryptographic operation, the MAC
a
operation . A

And if we use Authentication-then-Encryption, we will get

E(m + A(a+m))
which means we first encrypt concatenated and , then concatenate the resulted MAC
By clicking “Accept all cookies”, you agree Stack Exchange
a m
code with , and then do the encryption. Notice is effectively protected by two layers of
can store cookies on your device and disclose information in
accordance with mour Cookie Policy. a
cryptographic operations, both and . A E

Now suppose the authentication method is somehow broken and the encryption is not, which
is not that far-fetched since some MAC algorithms (like HMAC-MD5) is indeed found weak,
then will be fully exposed to tampering when using Encryption-then-Authentication. The
a
same cannot be said for Authentication-then-Encryption.
 Update on 2016-09-27:
I agree with some of the top comments that applying a cipher multiple times doesn't always
lead to better security so I retracted that statement. But it actually is not relevant to my main
point of AtE provides additional layer of security since we are not applying the same cipher to
the same data twice in these A/E schemes.
Share Improve this answer Follow edited Dec 26, 2017 at 4:04 answered Sep 26, 2016 at 18:31
Squeamish Ossifrage Penghe Geng
49.8k 3 121 230 346 2 8

There is a good reason why we use 3DES rather than 2DES, don't you think? And if AES is broken,
don't you think we'd loose confidentiality whichever encryption scheme we use (among about every
cryptographic device having to be redesigned)? – Maarten Bodewes ♦ Sep 26, 2016 at 20:35
4 “If we agree applying a cypher multiple times is more secure than once” — cryptographers don't
agree with this. At most, you can increase the strength of the keys, but that's only an issue if key size
is an issue as in DES's 56 bits. AES uses a minimum of 128 bits, key size isn't an issue. (It might be if
quantum computing delivers, but then we'd just switch to 256-bit keys.) Is there anything in your
answer that doesn't depend on the invalid argument that multiple encryptions are a good thing?
– Gilles 'SO- stop being evil' Sep 26, 2016 at 20:52
3 @MaartenBodewes That reason doesn't apply to algorithms with sufficiently large keys that make
brute-force attacks infeasible and you just use double encryption to increase the effective number of
rounds and in order to make it more resistant to cryptoanalysis. – CodesInChaos Sep 26, 2016 at
20:54
@CodesInChaos Yeah, my reason to make this answer invalid would only be correct if the reason of
Gilles to make this answer incorrect would not apply. Unfortunately, two wrongs....
– Maarten Bodewes ♦ Sep 26, 2016 at 21:59
@MaartenBodewes A critical security system needs to consider the worst scenario and whether the
system has a graceful downgrade rather than a total disaster. If AES is broken, yes we will lost
confidentiality, but if we can still keep authentication that will be better than nothing. For a lot of
applications, authentication is actually more important than confidentiality. – Penghe Geng Sep 27,
2016 at 14:59

Protected question. To answer this question, you need to have at least 10 reputation on this site (not
counting the association bonus). The reputation requirement helps protect this question from spam and
non-answer activity.
By clicking “Accept all cookies”, you agree Stack Exchange
can store cookies on your device and disclose information in
accordance with our Cookie Policy.

Start asking to get answers

Find the answer to your question by asking.
Ask question
Explore related questions
encryption protocol-design mac authenticated-encryption
See similar questions with these tags.

By clicking “Accept all cookies”, you agree Stack Exchange

can store cookies on your device and disclose information in
accordance with our Cookie Policy.