# Cipher Suites Demystified

## TLS, HTTPS, DSA, HMAC, DHE, RSA, ECDHE, AES, GCM, CCM, ECDSA, ChaCha20, SHA, Poly1305, AEAD

by Joe Honton*In this episode Ken “powers through” the nomenclature used to define cipher suites.*

Ken needed to understand how to configure his web server to get the best HTTPS performance. Since his knowledge of cryptography was still rudimentary, he thought it best to review things before going any further.

First, cryptographic systems are bidirectional — they encode plain text into ciphered text, and decode ciphered text back into its original.

Of course, when dealing with publicly exchanged text, the trick is to prevent anyone but the intended party from using the system to decode the ciphered text.

Cryptographic systems for websites do this with *cipher suites*, which comprise three or four algorithms, each with a distinct purpose.

- An asymmetric key exchange algorithm
- A digital signature algorithm (DSA)
- A symmetric encryption algorithm
- An optional hash-based message authentication code (HMAC)

Cryptographic algorithms are not kept secret. In fact, they are published, and widely circulated, and rigorously examined. Instead, algorithms rely on secret keys — known only to the parties involved — to keep the ciphered text safe from prying eyes.

Ken knew that *cipher suites* are a collection of algorithms that work together to make TLS and HTTPS safe and fast. But all those acronyms made his head spin.

He needed to break it down to make any sense of it.

#### Asymmetric algorithms

The *TLS handshake* is where browsers and servers initially negotiate which cipher suite to use. The rest of HTTPS then uses the agreed-upon cipher suite for routine traffic.

The three main algorithms used for the initial TLS handshake are:

**DHE**the Diffie-Hellman Ephemeral key exchange algorithm**RSA**named after its inventors Rivest–Shamir–Adleman**ECDHE**Elliptic-curve Diffie–Hellman exchange

These three are classified as *asymmetric algorithms*, because one party has a secret key and the other party has a public key.

Ken had recently learned how browsers and servers use the Secret Handshake to negotiate which cipher suite to use during an HTTPS session. So it made sense that asymmetric algorithms were used for that secret key exchange.

#### Symmetric algorithms

In contrast *symmetric algorithms* have a single key that is known to both parties. Symmetric algorithms are faster to compute, but are not suitable for use in website certificates, where the parties (browser and server), don't know and don't fully trust each other, and thus can't share the secret key.

Symmetric algorithms *are* suitable however *after* the initial TLS handshake protocol — that's what the handshake is all about: creating a shared secret for use during the bulk of the HTTPS communication.

The four most popular symmetric algorithms for HTTPS traffic are:

**AES**Advanced Encryption Standard**AES-GCM**AES Galois/Counter mode**AES-CCM**AES Counter with CBC-MAC (cipher block chaining message authentication code)**ChaCha20**a.k.a. Salsa20

Cryptographic strength is a security measurement: how safe is the ciphered text when placed under a brute force attack? The strength of an algorithm is correlated to the length of the secret key. Longer keys are stronger. Key length is expressed as a number of bits. Commonly used values are 128 and 256. Symmetric algorithms are identified by their acronym and their key length. So something like AES128 or AES256.

#### Cryptographic pairs

In practice, HTTPS uses a pair of algorithms. One of the asymmetric algorithms is used during the initial TLS handshake, and one of the symmetric algorithms is used for encryption/decryption of HTTPS traffic.

There are many combinations of these two. Each combination is formally identified in software by joining the two chosen acronyms. For example, the `openssl`

library implements these pairs for use with TLS 1.2:

pair identifier | TLS handshake protocol | HTTPS traffic

---------------- | ---------------------- | -------------------

ECDHE-AES256-GCM | ECDHE | AES256-GCM

ECDHE-CHACHA20 | ECDHE | CHACHA20

ECDHE-AES256-CCM | ECDHE | AES256-CCM

ECDHE-AES128-GCM | ECDHE | AES128-GCM

ECDHE-AES128-CCM | ECDHE | AES128-CCM

ECDHE-AES128 | ECDHE | AES128

---------------- | ---------------------- | -------------------

AES256-GCM | RSA | AES256-GCM

AES256-CCM | RSA | AES256-CCM

AES128-GCM | RSA | AES128-GCM

AES128-CCM | RSA | AES128-CCM

AES256 | RSA | AES256

AES128 | RSA | AES128

---------------- | ---------------------- | -------------------

DHE-AES256-GCM | DHE | AES256-GCM

DHE-CHACHA20 | DHE | CHACHA20

DHE-AES256-CCM | DHE | AES256-CCM

DHE-AES128-GCM | DHE | AES128-GCM

DHE-AES128-CCM | DHE | AES128-CCM

DHE-AES256 | DHE | AES256

DHE-AES128 | DHE | AES128

But simply choosing a pair of asymmetric/symmetric algorithms is not sufficient to fully identify a *cipher suite*. In order to do that, it is also necessary to specify rules for ensuring authentication and integrity.

#### Authentication

*Authentication protocols* provide the receiver with a guarantee that the identity of the sender really is who he claims to be. There are two common digital signature algorithms used by TLS that provide this guarantee:

**RSA**Rivest–Shamir–Adleman**ECDSA**Elliptic Curve Digital Signature Algorithm

When obtaining a cert from a certificate authority, the requestor must specify whether it will be RSA or ECDSA. Each type must follow a chain of authority up to the root that uses the same algorithm. The newer ECDSA certs, while safer, cannot be used with many of the older cipher suites. The popular, free, LetsEncrypt certs are only RSA at this time (2019).

#### Integrity

*Integrity protocols* make sure that the data received is the same as the data sent. This is typically accomplished using a hashing function. It goes like this: the server computes a hash of the data sent; the browser computes a hash of the data received; if the two hashes are the same, then the data hasn't been tampered with.

The most common HMACs (hash-based message authentication codes) for HTTPS data integrity are from the standardized family of Secure Hash Algorithms. These algorithms are identified by their acronym and the number of bits in the final hash. So something like:

- HMAC-
**SHA**(160 bits) - HMAC-
**SHA256**(256 bits) - HMAC-
**SHA384**(384 bits)

Correctly implementing these HMACs was a source of confusion in the industry. So now there is an alternative to using them separately: AEAD (authenticated encryption with associated data). In this scheme, the symmetric encryption algorithm handles message authentication internally, and the separate HMAC does not need to be used. Three of the previously identified symmetric algorithms use this new AEAD scheme: GCM, CCM and ChaCha20.

Poly1305 is an alternative way to verify data integrity that involves the use of the prime number 2^{130}−5.

#### Cryptography nomenclature

We can turn the previous list of asymmetric/symmetric pairs into a list of cipher suites by adding a digital signature algorithm (DSA) and, when required, a hash-based message authentication code (HMAC). Here is the same list of TLS 1.2 pairs from before, with the necessary authentication and integrity algorithms:

##### ECDSA certificates

cipher suite | DSA | AEAD | HMAC

----------------------------- | ----- | ----------- ------

ECDHE-ECDSA-AES256-GCM-SHA384 | ECDSA | GCM-SHA384 |

ECDHE-ECDSA-CHACHA20-POLY1305 | ECDSA | POLY1305 |

ECDHE-ECDSA-AES256-CCM | ECDSA | CCM |

ECDHE-ECDSA-AES128-GCM-SHA256 | ECDSA | GCM-SHA256 |

ECDHE-ECDSA-AES128-CCM | ECDSA | CCM |

ECDHE-ECDSA-AES128-SHA256 | ECDSA | | SHA256

##### RSA certificates

cipher suite | DSA | AEAD | HMAC

----------------------------- | ----- | ----------- ------

ECDHE-RSA-AES256-GCM-SHA384 | RSA | GCM-SHA384 |

ECDHE-RSA-CHACHA20-POLY1305 | RSA | POLY1305 |

ECDHE-RSA-AES128-GCM-SHA256 | RSA | GCM-SHA256 |

ECDHE-RSA-AES128-SHA256 | RSA | | SHA256

ECDHE-RSA-AES256-SHA † | RSA | | SHA

ECDHE-RSA-AES128-SHA † | RSA | | SHA

----------------------------- | ----- | ----------- ------

AES256-GCM-SHA384 | RSA | GCM-SHA384 |

AES256-CCM | RSA | CCM |

AES128-GCM-SHA256 | RSA | GCM-SHA256 |

AES128-CCM | RSA | CCM |

AES256-SHA256 | RSA | | SHA256

AES128-SHA256 | RSA | | SHA256

AES256-SHA † | RSA | | SHA

AES128-SHA † | RSA | | SHA

----------------------------- | ----- | ----------- ------

DHE-RSA-AES256-GCM-SHA384 | RSA | GCM-SHA384 |

DHE-RSA-CHACHA20-POLY1305 | RSA | POLY1305 |

DHE-RSA-AES256-CCM | RSA | CCM |

DHE-RSA-AES128-GCM-SHA256 | RSA | GCM-SHA256 |

DHE-RSA-AES128-CCM | RSA | CCM |

DHE-RSA-AES256-SHA256 | RSA | | SHA256

DHE-RSA-AES128-SHA256 | RSA | | SHA256

DHE-RSA-AES256-SHA † | RSA | | SHA

DHE-RSA-AES128-SHA † | RSA | | SHA

† Cipher suites that predate TLSv1.2 are still needed for compatibility with older browsers.

Ken's eyes started to glaze over. Thirty years of sophisticated mathematical transformations crammed into a bunch of three letter acronyms was a lot to take in.

But wait, these are just the TLS 1.2 cipher suites. Guess what? TLS 1.3 is already here.

*Ken decided being a CyberOps specialist wasn't his thing after all.*

*No minifig characters were harmed in the production of this Tangled Web Services episode.*

Follow the adventures of Antoní, Bjørne, Clarissa, Devin, Ernesto, Ivana, Ken and the gang as Tangled Web Services boldly goes where tech has gone before.