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 2130−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.
