Take the 2-minute tour ×
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.

Encrypt-then-Authenticate (EtA) seems to generally be considered the better option, compared to Authenticate-then-Encrypt (AtE) (see this Crypto.SE question, for example). The people writing the RFC for TLS 1.2 seem to have been aware of this, but have chosen to use AtE anyway.

Is there a reason why this is the case? Is this a case of "Someone standardized something at some point and now we're stuck with it for backwards compatibility, even though we know it's bad", or is there a good reason why AtE is better for TLS?

Clarification, because this wasn't very well-written originally: I am referring to the actual encrypted channel after the handshake has finished. It's clear that you have to authenticate the server and perform a key exchange before you can perform any useful form of encryption.

share|improve this question

2 Answers 2

up vote 7 down vote accepted

SSL was designed long ago when encrypt-then-MAC wasn't that popular yet. Even TLS 1.2, published in 2008, is pretty old by now, and while encrypt-then-MAC was preferred by then, the practical risks were underestimated for a long time. Padding oracles attacks became well known after several high profile attacks in 2010.

With stream ciphers, MAC-then-encrypt is safe and easy to implement correctly. With CBC it's trickier, but technically the way it's used in TLS is provably secure if you ensure that the attacker doesn't learn anything about the cause of a detected manipulation (invalid padding vs incorrect MAC etc).

The choice of MAC-then-encrypt has lead to several weaknesses over the history of SSL and TLS, including POODLE and Lucky 13.

  • Lucky 13 was a timing attack, which gave an attacker information about why decryption failed, invalidating the proof.
  • POODLE was an attack against SSL 3.0 (and some careless TLS implementations) which didn't have as strict padding validation requirements as newer versions of TLS.

In response to these attacks TLS implementations were carefully written to avoid side channel attacks, working around these weaknesses.

There is a draft TLS extension (Encrypt-then-MAC for TLS and DTLS draft-gutmann-tls-encrypt-then-mac) to use encrypt-then-MAC, but it didn't gain much traction and still hasn't been finalized.

TLS 1.3 will only support AEAD suites, where each suite is responsible for ensuring both confidentiality and authenticity, instead of combining MAC and encryption at the protocol level. So in TLS 1.3 this problem will finally be fixed.

share|improve this answer
So, basically, it really is a case of "someone standardized it like this and they never got around to changing it because of backwards compatibility". Figured as much, but good to have it confirmed. Thanks! –  malexmave May 24 at 11:24

if you do encrypt first you have to have pre-shared secret keys between client and servers? once master secret is generated then Record protocol job is to encrypt/decrypt.

share|improve this answer
I think you misunderstood the question. I was referring to the actual operation of the protocol after the handshake has finished, and the order in which the encrypted content of the connection is encrypted and authenticated. You seem to be talking about the handshake protocol itself. –  malexmave May 24 at 10:38
I re-read the question and noticed that this was indeed not very clear. I have updated it to make this more obvious. –  malexmave May 24 at 10:41

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.