What is the advantage of AEAD ciphers? Why is the TLS working group pushing for them? I thought modern cipher suites require SHA256 for authentication. What advantage is there to including Poly1305?

Slight additional question: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 has GCM and SHA256. What is GCM used for, and what is SHA256 used for? It seems all one needs is GCM.


2 Answers 2


AEAD cipher implementations are generally encrypt-then-authenticate internally (while the CBC ciphers in OpenSSL were not). TLS really was in need to get rid of the authenticate-then-encrypt which required special handling of the CBC code for block ciphers such as AES. The AEAD ciphers - regardless of the internal structure - should be immune to the problems caused by authenticate-then-encrypt.

AEAD algorithms generally come with a security proof. These security proofs are of course dependent on the underlying primitives, but it gives more confidence in the full scheme none-the-less.

These ciphers are often single pass (OCB, not often used), 1.5 pass (GCM, Poly1305) or 2 pass (EAX). That means that they generally have an execution speed advantage over two pass schemes using CBC + (H)MAC. Even a scheme as EAX can have performance advantages if a higher level language (Java, Python etc.) is used to implement TLS. This is because it is easier to create a fully optimized implementation for one algorithm (EAX) than for a combination of two algorithms at protocol level (CBC + HMAC). Internally EAX is simply CTR + CMAC.

Furthermore AEAD schemes generally can be (forced to) adhere to RFC 5116. That means that there is only one interface required for all of the AEAD ciphers with regards to the handling of the IV and plaintext. It is of course possible to let CBC + HMAC adhere to this RFC as well though.

Speed and security is probably the reason for Google to already support ChaCha20 + Poly1305/AES in Chrome. With such a big elephant in the room it is kind of hard to ignore this scheme by Daniel J. Bernstein (et all). It's a 1.5 pass AEAD cipher that uses a fast stream cipher underneath, so it's pretty efficient overall.

  • 3
    $\begingroup$ Note that I think it is extremely stupid to include the authentication tag directly in the ciphertext as RFC 5116 does. It requires the decryption side to buffer the ciphertext until the location of the authentication tag is found. This makes for a horrible implementation that is not online nor symmetric for encryption/decryption. API developers certainly should not follow this example. I really should make this a blog post soon. $\endgroup$
    – Maarten Bodewes
    Commented Jul 31, 2015 at 13:25
  • $\begingroup$ Could you elaborate on this point? It doesn't have to be at length, just enough to have an idea of the problems you're speaking of. $\endgroup$ Commented Jul 31, 2015 at 17:26
  • 1
    $\begingroup$ During encryption you can directly feed the plaintext to the internal encryption function (e.g. to perform CTR mode encryption in GCM, EAX or CCM). You can directly store the ciphertext, possibly in place. You cannot do this during decryption because you may be either dealing with the ciphertext or the tag. So you get update functions that return more or less plaintext compared to the ciphertext. If you have a doFinal method it may still need to return plaintext as well. So you need special buffer handling for decryption, not encryption. In implementations (Bouncy) it takes 33% more room. $\endgroup$
    – Maarten Bodewes
    Commented Jul 31, 2015 at 23:44
  • $\begingroup$ @MaartenBodewes If the authentication tag precedes the ciphertext, would that implementation issue you explained still have to persist? $\endgroup$
    – foo
    Commented Sep 30, 2022 at 11:24
  • $\begingroup$ No, because you do need to know the size in advance anyway. However, now you are not compliant anymore with most of the protocols and API's out there. That's why I advocate for an API to indicate a - possibly separate - buffer for the authentication tag. $\endgroup$
    – Maarten Bodewes
    Commented Sep 30, 2022 at 20:26

What is the advantage of AEAD ciphers?

That depends one the scheme, but often it means you:

  • Trust only one algorithm, not two.
  • Perform only one pass (an ideal in the world of AEAD, not a consequence of it).
  • Save on code and sometimes on computation as well.

The code savings can matter in embedded and IoT settings.

Why is the TLS working group pushing for them?

I haven't been following the IETF TLS WG itself, but it's rather hard to use an AEAD mode cipher incorrectly. In general, there are fewer mistakes to make and a larger area covered by KATs from the cryptography commuity.

I thought modern cipher suites require SHA256 for authentication. What advantage is there to including Poly1305?

SHA256 is a solid hash and I assume you mean using it in HMAC for authentication. That is, for example, SuiteB (SECRET). It also requires trusting SHA256 and your encryption algorithm along with the performance and memory requirements of SHA256, which might not be so great.

From the poly1305 portion of cr.yp.to:

Poly1305-AES has several useful features:

  • Guaranteed security if AES is secure. There's a theorem guaranteeing that the security gap is extremely small (n/2^(102) per forgery attempt for 16n-byte messages) even for long-term keys (2^64 messages). The only way for an attacker to break Poly1305-AES is to break AES.
  • Cipher replaceability. If anything does go wrong with AES, users can switch from Poly1305-AES to Poly1305-AnotherFunction, with an identical security guarantee.
  • Extremely high speed. My Poly1305-AES software takes just 3843 Athlon cycles, 5361 Pentium III cycles, 5464 Pentium 4 cycles, 4611 Pentium M cycles, 8464 PowerPC 7410 cycles, 5905 PowerPC RS64 IV cycles, 5118 UltraSPARC II cycles, or 5601 UltraSPARC III cycles to verify an authenticator on a 1024-byte message. Poly1305-AES offers consistent high speed, not just high speed for one favored CPU.
  • Low per-message overhead. My Poly1305-AES software takes just 1232 Pentium 4 cycles, 1264 PowerPC 7410 cycles, or 1077 UltraSPARC III cycles to verify an authenticator on a 64-byte message. Poly1305-AES offers consistent high speed, not just high speed for long messages. Most competing functions are designed for long messages and don't pay attention to short-packet performance.
  • Key agility. Poly1305-AES can fit thousands of simultaneous keys into cache, and remains fast even when keys are out of cache. Poly1305-AES offers consistent high speed, not just high speed for single-key benchmarks. Almost all competing functions use a large table for each key; as the number of keys grows, those functions miss the cache and slow down dramatically.
  • Parallelizability and incrementality. Poly1305-AES can take advantage of additional hardware to reduce the latency for long messages, and can be recomputed at low cost for a small modification of a long message.
  • No intellectual-property claims. I am not aware of any patents or patent applications relevant to Poly1305-AES.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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