1
$\begingroup$

My lecture notes state that of the AES operating modes ECB, CBC, CTR, CCM (CTR+CBC MAC) and GCM, only CCM and GCM provide authenticity. In CCM, as I understand it, the authenticity lies in the MAC, i.e. the symmetric key.

AES-GCM calculates the authentication tag (AT) using, among other things, the additional authenticated data (AAD) and the symmetric key. According to the specification, the AAD must remain unencrypted.

  • How then is the AAD supposed to be authentic? (Example?)
  • Does the authenticity of AES-GCM then also lie in the symmetric key?
  • If yes, why are the other operating modes not authentic if they also use a symmetric key?
Improve this question
$\endgroup$
1

1 Answer 1

Reset to default
1
$\begingroup$

Both GCM and CCM turn a regular block cipher into what we call an AEAD (authenticated encryption with additional data). Both algorithms provide encryption with what is effectively counter (CTR) mode and a MAC, combined into one algorithm with a single nonce and key.

The difference in how CCM and GCM authenticate the data is the major difference in the modes. CCM uses a variant of CBC-MAC to authenticate the data and GCM uses a polynomial (Carter-Wegman-style) MAC. Due to the requirements of using CBC-MAC in a secure way, the length is prefixed to the data, so with CCM one must typically know the data length ahead of time, whereas GCM doesn't have this problem.

Both algorithms require the use of a unique nonce plus a symmetric key. Anyone who knows the symmetric key can encrypt and decrypt data as well as create and verify valid messages.

The reason that ECB, CBC, CTR, CFB, OFB, and the like don't provide authenticity is that they only encrypt the data. An AEAD produces encrypted data plus a tag, which is traditionally appended to the message. This tag (and its correct verification) provides authenticity, and can be thought of as the output of a MAC. However, the five modes I mentioned above don't provide a tag, and as a result, they don't provide any authenticity. As a result, they should be used with a standalone MAC, such as HMAC with a secure hash function, in almost all cases.

The additional data is usually unencrypted for practical reasons. For example, in TLS, the packet header and sequence number are authenticated, but the packet header cannot be encrypted (since it's needed to parse the data properly) and the sequence number is not sent at all (it's an increasing integer kept as part of the state). This approach prevents replay attacks and, in some protocols, things like protocol downgrades. In any event, any change to either the encrypted message or the additional data will cause the tag to fail to verify with very high probability, and thus the message will be rejected.

Improve this answer
$\endgroup$
6
  • 1
    $\begingroup$ Ok, I understand that the "tag" (MAC) at GCM and CCM provides integrity unlike the other modes of operation. But I am solely concerned with authenticity: "How do I know for sure that I am communicating with A?" As you explained, with GCM, authenticity is ensured by the AAD, as this data is not encrypted but is authenticated by the embedded protocol, for example TLS. With CCM, I don't see the point of authenticity: "How do I know for sure that I have agreed the symmetric key with A to calculate the CBC-MAC?" At this point, doesn't CCM offer no more authenticity than the other AES modes? $\endgroup$
    – user946822
    Jun 25 at 11:54
  • 1
    $\begingroup$ @user946822 The tag authenticates both the AAD and the encrypted payload, not the other way around. AAD stands for "additionally authenticated data", it does not authenticate the tag, it's authenticated by the tag. $\endgroup$
    – DannyNiu
    Jun 25 at 12:02
  • 1
    $\begingroup$ To know which entity you're communicating with requires a signature of a challenge. Entity authentication is unrelated to message authentication, AEADs only handle the latter. In TLS, the server (and sometimes client) signs a challenge during the same "handshake" where the symmetric AEAD key is generated. $\endgroup$
    – SAI Peregrinus
    Jun 25 at 12:21
  • 1
    $\begingroup$ @SAIPeregrinus Message authentication is precisely the point: This authenticity is based exclusively on the trust that the symmetric key (and the nonce) has been determined with the correct communication partner, right? And this is ensured by the signature in the TLS handshake? $\endgroup$
    – user946822
    Jun 25 at 12:27
  • $\begingroup$ @SAIPeregrinus: not quite. Through TLS1.2 if a forward-secret (FF)DHE or ECDHE keyexchange is used, server signs only ServerKeyExchange body which should be unique but client can't enforce it; for plain-RSA keyexchange (now rare) there is no signature and server proves identity by recovering and using client's PremasterSecret. In either case client optionally signs transcript which includes both client and server nonces, and ephemerals if used. In TLS1.3 only xxDHE is used (except for PSK) and both server and optional client signatures are on transcript. $\endgroup$
    – dave_thompson_085
    Jun 26 at 4:03

Your Answer

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

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