6

In the answer of the following post: Why was AES CBC removed in TLS 1.3?, I quote the following from the chosen answer:

After the Lucky13 attack (a timing oracle caused by MAC-then-encrypt), it was thought that TLS should change ordering of the operations. Changing order of the operations would have affected the backwards compatibility with previous implementations so it was after all thought that it is more practical to switch to authenticated encryption only.

In the answer, it is assumed that AES-CBC in TLS 1.2 is not Authenticated Encryption (reference to the last part of the quote: it is more practical to switch to authenticated encryption only.

My questions:

  1. When can I consider a ciphersuite an Authenticated Encryption?

  2. Is AES-CBC in TLS 1.2 an Authenticated Encryption (it uses MAC-then-Encrypt construction).

  3. Do padding attacks in AES-CBC render it considered non-Authenticated Encryption cipher?

Mike Edward Moras
  • 18,161
  • 12
  • 87
  • 240
user9371654
  • 457
  • 1
  • 6
  • 12

2 Answers2

8

When can I consider a ciphersuite an Authenticated Encryption?

To cite from Wikipedia: Authenticated Encryption:

Authenticated encryption ... is a form of encryption which simultaneously provides confidentiality, integrity, and authenticity assurances on the data.

Note the focus on simultaneously.

Is AES-CBC in TLS 1.2 an Authenticated Encryption (it uses MAC-then-Encrypt construction).

Since the authentication tag in the form of MAC is added before and not during encryption it can not be considered authenticated encryption. This allows the padding oracle attacks because this means that the authentication tag can only be verified after decryption.

Maarten Bodewes
  • 96,351
  • 14
  • 169
  • 323
Steffen Ullrich
  • 1,613
  • 10
  • 11
3

When can I consider a ciphersuite an Authenticated Encryption?

If properly implemented, all TLS ciphersuites provide authenticated encryption. The caveat here is that

  1. The implementation actually must return $\perp$ (math-jargon for "error") if the decryption was unsuccessful, it must not tell anybody why exactly $\perp$ was returned.
  2. The time it takes for an implementation to return $\perp$ must not depend on any secret values (such as the key contents or the message contents).

If implementations (eg BearSSL) achieve these two constraints, then yes, the ciphersuites provide authenticated encryption (in the technical cryptographical sense).

However, some people (eg Google) don't consider the the CBC-based suites authenticated encryption, because they use a generic construction specified by the TLS protocol. In such a context, only ciphersuites that use an atomic primitive providing authenticated encryption (atomic meaning indivisible from the point of view of the TLS protocol) counts. As TLS really uses the CBC modes to do HMAC-then-CBC they don't count, as opposed to the modes like GCM, CCM, EAX or ChaCha-Poly1305 which have specialized security reductions and can / should not be split up from the point of view of TLS.

Is AES-CBC in TLS 1.2 an Authenticated Encryption

see above.

Do padding attacks in AES-CBC render it considered non-Authenticated Encryption cipher?

No, attacks do not change whether a (theoretical) construction satisfies a security definition. The thing is with the theoretical security definitions: They are based on a security model and if the real world isn't reflected by this security model, then a cipher may satisfy the model, but fail in the real world. What does this mean? Timing information (as exploited by Lucky13) is not part of the (formal) security model for authenticated encryption. On the other hand, a construction that has more than one error message is not authenticated encryption scheme, because these may only have one (generic) error message.

SEJPM
  • 46,697
  • 9
  • 103
  • 214