0

As per TLS 1.3 RFC 8846, following 5 ciphers are supported.

TLS_AES_128_GCM_SHA256  
TLS_AES_256_GCM_SHA384  
TLS_CHACHA20_POLY1305_SHA256  
TLS_AES_128_CCM_SHA256  
TLS_AES_128_CCM_8_SHA256  

But I noticed none of my tested browsers request for CCM ciphers in their ClientHello.
Why is that?
Under what condition these ciphers will be requested?.
As per this answer CCM can be good for embedded system.

Even openssl header file ssl.h didn't have CCM cipher.

#  define TLS_DEFAULT_CIPHERSUITES "TLS_AES_256_GCM_SHA384:" \
                                   "TLS_CHACHA20_POLY1305_SHA256:" \
                                   "TLS_AES_128_GCM_SHA256:"

migrated from crypto.stackexchange.com Jun 13 at 10:47

This question came from our site for software developers, mathematicians and others interested in cryptography.

3

They will be requested if the client supports them and if they are enabled. Like you mentioned, for example, OpenSSL does not enable them by default. They don't seem to provide any justificative other than it's "rarely used". But consider that most desktop CPUs support instructions for accelerating GCM, making it probably faster than CCM.

  • Thanks, but what if server is running on embedded systems and for it, CCM is preferable, how can it ask browser to use CCM in it Client Hello? – Chits Jun 13 at 2:08
  • 1
    I'm ready to be corrected but afaik it can't. The client (browser) lists all ciphers it supports in its Client Hello message, the server then selects one of them. – tum_ Jun 13 at 5:55
  • @tum_ I agree , but I notice that Chrome or Firefox isnt sending the last 2 ciphers in clienthello, is there some settings in browsers to enable those ciphers? – Chits Jun 13 at 6:12
  • 1
    Well, that's offtopic here. You might try googling for this particular info. – tum_ Jun 13 at 6:16
  • Yes, the cipher suites sent in the handshake are a configuration option. If you want to use CCM mode you have to enable it in the client's configuration – mat Jun 13 at 9:08
2

On a Skylake (i7-6700hq) laptop, on a single core:

$ openssl version
OpenSSL 1.1.1  11 Sep 2018

$ openssl speed -evp aes-128-gcm
$ openssl speed -evp chacha20-poly1305
$ openssl speed -evp aes-128-ccm

The 'numbers' are in 1000s of bytes per second processed.
type               16 bytes       64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128-gcm        488169.02k  1231926.26k  2414630.74k  3816304.85k  4789598.50k  4845855.68k
chacha20-poly1305  246956.37k   476741.65k   946072.14k  1730753.88k  1871080.29k  1868974.56k
aes-128-ccm        184384.63k   531209.72k   878769.23k  1111729.15k  1197240.25k  1221242.40k

TLS record layer blocks are 16KB, so look at the right most column.

CCM is slower than ChaCha.

That's why reasonable chips won't try to use CCM.

The logic of modern cipher selection is this:

  1. If you can do AES fast and without side channel problems (e.g. AESNI) and you can do carry-less multiplication fast and without side channel problems (e.g. CLMUL):
    1. do AES-GCM.
  2. Else, if you have vector instructions (SSE, AVX, NEON, etc.):
    1. do ChaCha20-Poly1305.
  3. Else, if you have AES hardware:
    1. do AES-CCM.
  4. Else, if you have no acceleration at all:
    1. do ChaCha20-Poly1305 slowly.

Servers, laptops and smartphones are in category 1 or 2, so they don't offer CCM.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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