3
$\begingroup$

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?

$\endgroup$
  • $\begingroup$ You could probably create an AEAD scheme using MAC-then-encrypt and CBC / SHA-2, but proving it secure would be tricky, and any review would start by pointing out the padding oracle attack (or, if CTS is used, that it requires a message size larger than one block). $\endgroup$ – Maarten Bodewes May 20 '18 at 20:17
8
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ Reworded last sentence. It read "authentication" which is verification of the authentication tag rather than the calculation of the tag during encryption. $\endgroup$ – Maarten Bodewes May 20 '18 at 15:22
3
$\begingroup$

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.

$\endgroup$
  • 1
    $\begingroup$ Note that the definition is kind of fluid because you can question "atomar" as well. GCM runs GHASH before encryption / decryption (although it can be online as well), even if the tag is then encrypted / decrypted. And EAX mode is just AES-CTR with AES-CMAC. There was even a CBC-then-HMAC scheme proposed as AEAD cipher. Probably the only scheme that is completely atomar are one pass schemes such as OCB. $\endgroup$ – Maarten Bodewes May 20 '18 at 15:15
  • $\begingroup$ I've changed my opinion on this answer. AEAD schemes do not have to be atomar in the mathematical sense. They just need to be described in a separate paper and then shown to be secure given the requirements for an AEAD scheme. "shown to be secure" assuming that the underlying primitives are secure of course. $\endgroup$ – Maarten Bodewes May 20 '18 at 15:30
  • 1
    $\begingroup$ By "atomar meaning undividable", do you mean "atomic meaning indivisible"? Whatever the name, isn't this a property of the implementation rather than the scheme? $\endgroup$ – Gilles May 20 '18 at 22:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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