Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It only takes a minute to sign up.
Sign up to join this community
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.
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.
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$
What is the advantage of AEAD ciphers?
That depends one the scheme, but often it means you:
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.
