2
$\begingroup$

I know AES-GCM and AES-CCM but what is the difference between AES-CCM8 mode and AES-CCM mode ? Is it the length of the cipher?

$\endgroup$

2 Answers 2

3
$\begingroup$

8 is the tag length (in bytes).

CCM is a family of AEAD (authenticated encryption with associated data) algorithms which is parametrized by:

  • a block cipher algorithm (e.g. AES-128, AES-192, AES-256, Camellia-128, …) with a 128-bit block size;
  • a counter generation function;
  • a formatting function for the first block;
  • a tag length.

CCM is defined by NIST SP 800-30C.

In practice, everyone uses the counter generation and the formatting function specified in NIST SP 800-30C appendix A. The specification of the formatting function is in fact a family of functions with one parameter: the length of the AEAD field. So “AES-CCM” leaves three parameter ambiguous: the length of the AES key, the length q of the AEAD field and the length t of the tag.

The value of q has no direct impact on security. It limits the size of AEAD that can be transmitted, and it limits the size of the nonce. The value of t has an impact on security: a tag that is too short can be brute-forced. The tag length can be as low as 4 bytes, which is easy to brute-force. Such short tags are used in communication protocols where brute-forcing the tag would be an active attack and the probability of an active attack succeeding is considered acceptably low.

The parameters q and t are encoded in the first block of the data, so an implementation of CCM decryption-verification for a given block cipher can unambiguously decrypt and verify the input whatever those values are. Some protocols restrict q and t to specific values. For the tag length t, this is a security parameter. For q, this can allow implementations to be a bit simpler and makes interoperability easier (less risk of differences in support, consistent AEAD size limit, less burden on interoperability testing…).

Note that q and t are inputs to the tag calculation. Therefore the tag value depends on these parameters. In particular, for a given message, the n-byte CCM tag is not the truncation of the 16-byte tag to n bytes. (This is different for GCM, where GCM with a shorter tag is just GCM with the full-length tag truncated.)

If not specified explicitly, the tag length is usually the maximum possible, which is one block (128 bits = 16 bytes). This can also be written ”AES-CCM-16” (or typographical variants). “AES-CCM-8” means AES-CCM with a 64-bit = 8-byte tag, and so on.

For example, in TLS 1.2, CCM cipher suites are defined by RFC 6655 (and other RFC for Camellia and ARIA), with reference to RFC 5116 §5.3 and §5.4. RFC 6655 §3 specifies a 12-byte nonce, which is equivalent to saying that q = 3. xxx_CCM cipher suites use a maximum-length tag (t = 16), whereas xxx_CCM_8 cipher suites use a half-length tag (t = 8).

An 8-byte (64-bit) tag would be uncomfortably small in situations where the attacker can brute-force all possible tags. However, when the tag is used for TLS communication, if the attacker makes a wrong guess for the tag, the receiver will immediately close the connection, so each guess requires a new connection. This makes brute force very expensive. With DTLS, the receiver will accept a number of corrupted packets, so the attacker can make several guesses per connection, but an attack is still an active attack on an ongoing connection and it's often impractical for the attacker to try a non-negligible amount of guesses without saturating the receiver's bandwidth or triggering a flood defense.

$\endgroup$
6
  • $\begingroup$ so aes-ccm is safer than aes-ccm8? $\endgroup$
    – dawklrw
    May 16, 2022 at 2:20
  • $\begingroup$ There is a difference of passing the tag-validation and injecting data into the encrypted message, which results then in an "intended" decrypted value. Passing only the MAC may considered to be easier. But that results still in a "random payload" of the decrypted message. If that hurts, or is then detected by the next protocol layer, is not generally clear. The point seems to be more, that the overall savings of a 8 byte tag compared to a 16 byte tag may be not worth the larger risk. $\endgroup$ May 21, 2022 at 15:15
  • $\begingroup$ "In particular, for a given message, the n-byte CCM tag is not the truncation of the 16-byte tag to n bytes." then there are broken implementations out, that is exactly what is done in my experience, ccm8 just truncates the ccm16. $\endgroup$ May 21, 2022 at 15:18
  • $\begingroup$ @AchimKraus RFC 6655 states “The AEAD_AES_128_CCM_8 ciphertext consists of (…) the 8-octet authentication tag output of the CCM encryption operation” — note that it does not say that this is the truncation of the tag to 16 bytes. RFC 6655 refers to RFC 5116 which states “The formatting and counter generation function are as specified in Appendix A of [SP 800-38C]”. $\endgroup$ May 22, 2022 at 18:23
1
$\begingroup$

As defined in section 6.1 of RFC6655, AES-CCM8 differs in that the size of the authentication tag is 8 bytes (i.e. 64-bits) rather than 16 bytes (i.e. 128-bits) for AES-CCM. The NIST CCM specification in SP800-38C section 6.1 allows for a range of possible authentication tag lengths. Shorter tags can be considered as the most significant bits of longer tags. There is no difference in the encrypted payloads.

$\endgroup$
1
  • 2
    $\begingroup$ For CCM, shorter tags are not truncations of the full-length tag: the tag length is an input to the tag calculation. $\endgroup$ May 15, 2022 at 20:12

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.