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
From RFC 5246, section 6.2.3.3: AEAD Ciphers:
AEAD ciphers take as input a single key, a nonce, a plaintext, and "additional data" to be included in the authentication check, as described in Section 2.1 of [AEAD]. The key is either the client_write_key or the server_write_key. No MAC key is used.
I am not able to understand what it means? what difference it has compare to CBC?
TLS records need to be protected both for confidentiality (defence against an attacker learning their content) and for authenticity (defence against an attacker modifying them in transit). So they are protected by authenticated encryption.
Older TLS cipher suites do authenticated encryption by combining an unauthenticated encryption algorithm (a block cipher in CBC mode, or the stream cipher RC4) with a MAC (always HMAC). The encryption part and the authentication part are done by separate primitives so they each have their own key. CBC or RRC4 alone doesn't protect against modifications: a man-in-the-middle can modify the ciphertext, and this modification won't necessarily be detected. In TLS, such modifications allow, for example, padding oracle attacks such as Lucky Thirteen, because the CBC padding is not authenticated.
Newer TLS cipher suites (introduced in TLS 1.2) do authenticated encryption using an authenticated encryption primitive, such as a block cipher in GCM or CCM mode, or ChaCha20+Poly1305. The authentication primitive takes care of everything with a single key. Since authenticated encryption protects both the confidentiality and the authenticity of the data, if an attacker tries to modify the data in transit, this will be detected: when the recipient attempts to do the authenticated decryption on the ciphertext, the result will be an authentication failure and not a plaintext.
TLS is a communication protocol; both sides need to derive the same record protection key(s) from the shared master secret. The protocol definition specifies how to derive up to two keys from the master key. When using separate primitives for encryption and for authentication, one of the keys is used as the encryption key and the other as the authentication key. When using a single authenticated encryption primitive, one of the keys (somewhat arbitrarily, the encryption key) is used as the authenticated encryption key, and the other key isn't used.
Under the hood, authenticated encryption does something similar to encrypting with one key and a MAC with another key. But it's not exactly that, and the details depend on the authenticated encryption primitive. Each algorithm has its own method of deriving two keys from the original key, and using one key for a stream cipher and the other key for a one-time authenticator. A one-time authenticator is like a MAC, but isn't secure when the same key is used for different messages. (In the case of CCM, a single key is used for both parts.) As a consequence, the internal authentication key is derived not only from the original key but also from the nonce.
The AEADs are internally computing a hash value over the encrypted data. That hash is sent together with the encrypted data.
Adding a second hash as MAC together with a MAC key would not provide more security. Also applying a MAC key to the AEAD generated hash would not improve the security. Both variants would only increase the message size and slow down the processing speed.
Thus the additional MAC + MAC key are omitted.
