I've been looking into TLS cipher suites of OpenSSL and mbedTLS (previously called PolarSSL) and noticed that mbedTLS supports the CCM mode of operation (See list here), whereas OpenSSL does not. If I understand this correctly, this provides authenticated encryption and therefore covers the message hashing in TLS, like GCM.

Looking up CCM, I couldn't find much information on its security. How does it compare to GCM or SHA1/2?


mbedTLS TLS cipher suites with CCM:


2 Answers 2


GCM and CCM are both basically fine as far as typical TLS use goes, although there is a litany of caveats for them:

  1. Anything involving AES is likely to be vulnerable to timing side channel attacks, if you cannot guarantee that you are using hardware implementations of AES. (Portable C code cannot.)

  2. GCM is also likely to be vulnerable to different timing side channel attacks, if you cannot guarantee that you are using hardware Galois field arithmetic. (Portable C code cannot.)

  3. The length of the authentication tag directly affects security: the GCM and CCM suites use 128-bit tags, but the CCM-8 suites use 64-bit tags, so they cannot get better than a 64-bit security level against forgery.

  4. For both GCM and CCM, the security contract requires that the key never be reused with a nonce. If they were integrated into TLS sensibly, the protocol would mandate the use of sequential nonces, so that there is only one possible choice of nonce for each message and if a peer chooses any other nonce it will noisily fail to interoperate. TLS 1.3 will do this, but when GCM was first introduced for TLS, it was foolishly designed to allow the peers to choose nonces however they like, to hilarious effect, and CCM in TLS parroted the mistake.

You can't fix any of these problems except by picking an entirely different cipher suite, but you can check whether these are problems for mbedTLS or your particular deployment of it—make sure mbedTLS uses sequential nonces, for example, and take a close look at how it computes AES and GHASH.

Or, if mbedTLS and your clients support it, just always use ChaCha20/Poly1305 cipher suites instead, which have none of these issues.

  • $\begingroup$ Note that it is very possible to make secure AES implementations for a wide array of platforms in C. BearSSL for example does an excellent job at this. $\endgroup$
    – SEJPM
    Jul 24, 2017 at 19:25
  • 2
    $\begingroup$ Secure, yes. Fast, not really. If you look at the numbers quoted there, you'll see that the fast variable-time (vulnerable) AES code in BearSSL runs at 18 cpb, and the constant-time AES code costs 3-5x the cpb. In contrast, on the same CPU, naive portable constant-time C code for ChaCha should run at about 6 cpb, 3x faster than the variable-time AES and an order of magnitude faster than the constant-time AES. And BearSSL is extremely unusual in this respect. Does mbedTLS, as the OP is using, provide constant-time AES? Probably not, but I haven't audited it. $\endgroup$ Jul 25, 2017 at 2:03
  • $\begingroup$ So in quintessence one could say, currently with AES in TLS, GCM and CCM are both equally good (or bad). However CCM-8 is a little weaker due to the 64 bit tags. Is this correct? $\endgroup$
    – SaAtomic
    Jul 25, 2017 at 5:23
  • 1
    $\begingroup$ Yes. The difference in security between GCM and CCM is negligible compared to the issues I raised. $\endgroup$ Jul 25, 2017 at 6:15
  • 1
    $\begingroup$ Using mbedtls at work right now, implementing an alternate AES function to use a hardware module. The default code seems to have quite a lot of table lookups, but is a mess of macros and quite hard to follow. I assumed it's not constant time, thus the work to replace it with hardware. $\endgroup$ Apr 25, 2019 at 16:25

Looking up CCM, I couldn't find much information on its security. How does it compare to GCM or SHA1/2?

  • CCM is slower, because it needs two cipher calls per block instead of a field multiplication and a cipher call like in GCM. Note that this only holds if field multiplications can actually be implemented fast on your platform and / or you don't have hardware acceleration for AES.
  • CCM needs to know the message length before starting the encryption process. While a restriction in other scenarios, this is not a problem in TLS.
  • CCM is simpler. CCM really is just CTR with CMAC (a variant of CBC-MAC), it shouldn't be too hard to properly implement and certainly easier than GCM.
  • CCM is much nicer than GCM if you need to shorten tags. GCM puts an (even stronger) limit on the amount of data to be encrypted if you shorten the tag (see Appendix C of NIST SP 800-38D (PDF)), whereas this doesn't happen with CCM. For CCM the number of queries dominates (see Appendix B of NIST SP 800-38C (PDF)).

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.