As consultants in the field of applied cryptography, we often encounter the question of whether enabling encryption is enough to ensure the security of digital communication.
When a message is sent across a connection, normally a TLS/SSL connection is used to encrypt the data in the message. To create this connection, a TLS Handshake occurs. Inside of that Handshake, the client and server exchange available cipher suites to ensure they use the same ciphers during the TLS Handshake.
A cipher suite provides instructions on how to secure the TLS/SSL connection by providing information on which ciphers are used by the client or server to create keys, authenticate users, etc. Cipher suites must be traded between the client and server to ensure the ciphers used in the TLS Handshake match and the client and server can understand each other.
Now, let us take you behind the scenes and reveal how does a TLS handshake works:
Introduction
How does a TLS handshake work?
A TLS Handshake is the process undertaken between a client and server to create a secure connection and encrypt the data sent through that connection. A TLS Handshake contains the following steps:
- Client Hello
The client hello stage involves the client sending a request to the server to communicate. The TLS version, cipher suites supported, and a string of random bytes known as the “client random” are included in the hello.
- Server Hello
In the server hello, the server acknowledges the client hello and ensures it is using a TLS version that is compatible with the client TLS version. The server also selects a compatible cipher suite from the ones offered by the client, and sends its certificate, the server random (similar to the client random), and the public key to the client.
- Certificate Validation
The validity of the server’s certificate is then checked by the client through the certificate authority. The certificate authority, or CA, is a highly trusted entity given the responsibility of signing and generating digital certificates.
- Pre-Master String
In this stage, the client encrypts a random string of bytes, called the “Pre-Master String”, with the server’s public key and sends it back to the server. This ensures that only the server can decrypt the key with its own private key, which adds an extra layer of security to the process.
- Session Key Creation
The server then decrypts the pre-master key, and both the client and server create session keys from the client random, the server random, and the premaster string.
- Finished Messaging
Finally, the client and server send each other messages saying they have finished creating their keys, and they compare keys with each other. If the session keys match, the TLS Handshake is completed, and the session keys are used to encrypt and decrypt any data sent between the server and client.
Now that we understand how a TLS Handshake works, we can focus on cipher suites in a TLS Handshake specifically.
Cipher Suites
The cipher suite determines how encryption is applied, which algorithms are used, and the size of the encryption key. It encapsulates the key exchange, authentication, bulk data encryption, and algorithms governing the encryption process.
Components of a Cipher Suite
A cipher suite mainly consist of four different components:
- Key Exchange Algorithm
The information exchange process requires a secure connection to send unencrypted data or a key shared between the client and server. The client uses this key to encrypt data, and the server uses it to decrypt that data. Since one key is used for both encryption and decryption, symmetric encryption is used. To share that key, an algorithm called the key exchange algorithm was created to encrypt the symmetric encryption key in transfer. This ensures the integrity of the data and the security of the symmetric encrypting key.
The key exchange algorithm is an encryption algorithm shared between the client and server so each side of the connection can decrypt and use the symmetric encryption key. RSA, DH, ECDH, and ECDHE are all examples of key exchange algorithms. - Authentication Algorithm
This algorithm is a way of ensuring the identity of the sender. Usually, a password and username are used to authenticate the client. The most common authentication algorithms are RSA, DSA, and ECDSA.
- Bulk Data Encryption Algorithm
The bulk data encryption algorithm is used to encrypt the central body of the message. As the main part of the message is what attackers are attempting to steal or modify, the algorithm used here should be extremely secure. The most common bulk encryption algorithms used by cipher suites are AES, 3DES, and CAMELLA.
- Message Authentication Code (MAC) Algorithm
The MAC is a section of information sent along to authenticate the client. The MAC algorithm is the algorithm used to encrypt the MAC. The server compares the MAC received and the MAC they calculate to ensure they match. Normally, a Cyclic Redundancy Check algorithm, or CRC, is used with an MAC to check for damaged portions of the message, but a CRC cannot protect against intentional changes to the MAC.
If an attacker obtains the message, changes the MAC, and calculates a new checksum, then the server will never know that the MAC was changed. SHA-2 are commonly used MAC algorithms. MAC ensures both authenticity and integrity of the message.
An example of a version 1.2 cipher suite naming is TLS_DHE_RSA_AES256_SHA256. The first portion, TLS, specifies what the cipher suite is used for. TLS is the most common reason used for cipher suites. The second algorithm name, DHE, is the key exchange algorithm used. RSA is the authentication algorithm, AES256 is the bulk data encryption algorithm, and SHA256 is the MAC algorithm.
Ciphers Suites supported in TLS 1.2
Version 1.2 cipher suite names are short, but other cipher suite versions support different algorithms and are even shorter. The most widely used cipher suite version is version 1.2, even though version 1.3 already exists. The reason for using an older version over a newer version is the number of options offered by each version.
Version 1.2 cipher suite names are short, but other cipher suite versions support different algorithms and are even shorter. The most widely used cipher suite version is version 1.2, even though version 1.3 already exists. The reason for using an older version over a newer version is the number of options offered by each version.
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (Recommended)
- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (Recommended)
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (Weak)
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (Weak)
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Secure)
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Secure)
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (Weak)
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (Weak)
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (Weak)
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (Weak)
- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (Weak)
- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (Weak)
- TLS_DHE_RSA_WITH_AES_128_CBC_SHA (Weak)
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA (Weak)
- TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (Weak)
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (Weak)
- TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (Recommended)
- TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305 (Recommended)
- TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Recommended)
- TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 (Secure)
Cipher Suites supported in TLS 1.3
Version 1.3, on the other hand, only offers 5 ciphers and includes 2 algorithms in its naming. Version 1.2 also offers more secure algorithms compared to 1.3. The naming of the cipher suite and the amount number of ciphers offered in a cipher suite in version 1.3 shorten the TLS Handshake significantly, however. The name of the cipher used in version 1.3 looks like this: TLS_ AES_256_GCM_SHA384. The fewer ciphers used and the shorter the name, the faster the TLS Handshake.
- TLS_AES_256_GCM_SHA384 (Recommended)
- TLS_CHACHA20_POLY1305_SHA256 (Recommended)
- TLS_AES_128_GCM_SHA256 (Recommended)
- TLS_AES_128_CCM_8_SHA256 (Secure)
- TLS_AES_128_CCM_SHA256 (Secure)
Impact of Post Quantum Cryptography (PQC) on Cipher Suites
Quantum computers can break TLS encryption using modern ECC-based ciphers and algorithms like RSA and DSA in matters of hours as they rely on mathematical problems such as integer factorization and discrete logarithms(log). These problems are computationally infeasible for classical computers but can potentially be solved efficiently by quantum computers using Shor’s algorithm. This poses a direct threat to the security of existing cryptographic protocols, including those employed in TLS/SSL.
Cipher Suites need to be updated to incorporate post-quantum algorithms. For example, TLS 1.3, which currently uses algorithms like ECDHE and RSA for key exchange, must transition to quantum-safe alternatives. The redesign includes selecting post-quantum algorithms that balance security, performance, and bandwidth efficiency. For instance, ML-KEM (Initial Specification name- CRYSTALS-Kyber) is gaining popularity for sharing symmetric keys for general encryption.
Let’s have a closer look at NIST supported PQC algorithms:
For general encryption, which is used when accessing websites securely, NIST has selected the following algorithm.
- CRYSTALS-Kyber (Updated Name: ML KEM)
NIST recommends using Kyber in a so-called “hybrid mode”, combining it with established “pre-quantum” security protocols, such as elliptic-curve Diffie-Hellman. The submission includes three parameter sets designed for different security levels:
Kyber-512 aims at security roughly equivalent to AES-128
Kyber-768 aims at security roughly equivalent to AES-192
Kyber-1024 aims at security roughly equivalent to AES-256
For digital signatures, commonly used for verifying identities during digital transactions or signing documents remotely, NIST has selected the following three algorithms:
- CRYSTALS-Dilithium (Updated Name: ML DSA)
As an update for round 2 of the NIST project a variant of Dilithium, called Dilithium-AES was proposed. This variant uses AES-256 in counter mode instead of SHAKE to expand the matrix and masking vectors and sample the secret polynomials. The following variants of Dilithium are available:
Dilithium2-AES
Dilithium3-AES
Dilithium5-AES - FALCON (Updated Name: FN DSA)
Falcon is based on the theoretical framework of Gentry, Peikert and Vaikuntanathan for lattice-based signature schemes. Falcon achieves the following performance:
FALCON-512 (keygen (ms)- 8.64, keygen (RAM)- 14336, signs/s- 5948.1, verifies/s- 27933.0, pub size- 897, sig size- 666)
FALCON-1024 (keygen (ms)- 27.45, keygen (RAM)- 28672, signs/s- 2913.0, verifies/s- 13650.0, pub size- 1793, sig size- 1280)
To provide a comparison, Falcon-512 is roughly equivalent, in classical security terms, to RSA-2048, whose signatures and public keys use 256 bytes each. - SPHINCS+ (Updated Name: SLH DSA)
SPHINCS+ is a stateless hash-based signature scheme. It incorporates multiple improvements, specifically aimed at reducing signature size. The second-round submission of SPHINCS+ introduces a split of the above three signature schemes into a simple and robust variant for each choice of hash function. The robust variant is exactly the SPHINCS+ version from the first-round submission and comes with all the conservative security guarantees given before. The submission proposes three different signature schemes:
SPHINCS+-SHAKE256
SPHINCS+-SHA-256
SPHINCS+-Haraka
These signature schemes are obtained by instantiating the SPHINCS+ construction with SHAKE256, SHA-256, and Haraka, respectively.
A current TLS cipher suite, such as TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, when evolves to a post-quantum cipher, might look like TLS_KYBER_DILITHIUM_WITH_AES_256_GCM_SHA384.
The following table represents Post Quantum Cryptography Algorithms (NIST-Approved)
| CRYSTALS-Kyber | CRYSTALS-Dilithium | FALCON | SPHINCS+-SHA256 | SPHINCS+-Haraka | SPHINCS+-SHAKE256 |
| Kyber512 | Dilithium2 | FALCON-512 | SPHINCS+-SHA256-128f-robust | SPHINCS+-Haraka-128f-robust | SPHINCS+-SHAKE256-128f-robust |
| Kyber512-90s | Dilithium3 | FALCON-1204 | SPHINCS+-SHA256-128f-simple | SPHINCS+-Haraka-128f-simple | SPHINCS+-SHAKE256-128f-simple |
| Kyber768 | Dilithium5 | – | SPHINCS+-SHA256-128s-robust | SPHINCS+-Haraka-128s-robust | SPHINCS+-SHAKE256-128s-robust |
| Kyber768-90s | Dilithium2-AES | – | SPHINCS+-SHA256-128s-simple | SPHINCS+-Haraka-128s-simple | SPHINCS+-SHAKE256-128s-simple |
| Kyber1024 | Dilithium3-AES | – | SPHINCS+-SHA256-192f-robust | SPHINCS+-Haraka-192f-robust | SPHINCS+-SHAKE256-192f-robust |
| Kyber1024-90s | Dilithium5-AES | – | SPHINCS+-SHA256-192f-simple | SPHINCS+-Haraka-192f-simple | SPHINCS+-SHAKE256-192f-simple |
| – | – | – | SPHINCS+-SHA256-192s-robust | SPHINCS+-Haraka-192s-robust | SPHINCS+-SHAKE256-192s-robust |
| – | – | – | SPHINCS+-SHA256-192s-simple | SPHINCS+-Haraka-192s-simple | SPHINCS+-SHAKE256-192s-simple |
| – | – | – | SPHINCS+-SHA256-256f-robust | SPHINCS+-Haraka-256f-robust | SPHINCS+-SHAKE256-256f-robust |
| – | – | – | SPHINCS+-SHA256-256f-simple | SPHINCS+-Haraka-256f-simple | SPHINCS+-SHAKE256-256f-simple |
| – | – | – | SPHINCS+-SHA256-256s-robust | SPHINCS+-Haraka-256s-robust | SPHINCS+-SHAKE256-256s-robust |
| – | – | – | SPHINCS+-SHA256-256s-simple | SPHINCS+-Haraka-256s-simple | SPHINCS+-SHAKE256-256s-simple |
Round 4 of NIST’s Post-Quantum Cryptography (PQC) Standardization process
Several candidate algorithms have been put forward for consideration. These are the cryptographic algorithms that are still under evaluation to determine their suitability for standardization in a post-quantum era.
Round 4 candidate algorithms are designed to securely establish shared keys between parties in a communication system, typically through public-key cryptography. These algorithms are, as follows:
- BIKE (Binary Code-based Key Encapsulation)
BIKE is a code-based key encapsulation mechanism based on QC-MDPC (Quasi-Cyclic Moderate Density Parity-Check) codes submitted to the NIST Post-Quantum Cryptography Standardization Process. A public-key encryption system based on error-correcting codes. - Classic McEliece
The McEliece system was designed to be one-way (OW-CPA), meaning that an attacker cannot efficiently find the codeword from a ciphertext and public key, when the codeword is chosen randomly. It is a public-key cryptosystem based on the hardness of decoding a random linear code. - HQC (Hamming Quasi-Cyclic)
HQC (Hamming Quasi-Cyclic) is a code-based public key encryption scheme designed to provide security against attacks by both classical and quantum computers. It uses a class of error-correcting codes known as quasi-cyclic codes. - SIKE (Supersingular Isogeny Key Encapsulation)
It is a KEM based on the difficulty of finding isogenies between super singular elliptic curves, a relatively new approach in quantum-resistant cryptography. It contains two algorithms:
A CPA-secure public key encryption algorithm SIKE.PKE
A CCA-secure key encapsulation mechanism SIKE.KEM
Long-term benefits of PQC in Cipher Suites
Vadium Lyubashevsky, an IBM cryptography researcher, mentioned that “Algorithms based on lattices when designed properly, are actually more efficient than algorithms being used today,” he said. “While they might be larger than classical cryptography, their running time is faster than the classical algorithms based on discrete, larger RSA or elliptic curves”.
Incorporating PQC in cipher suites brings several benefits, such as:
- Quantum-resistant security
Using PQC algorithm leads to stronger encryption so it can withstand quantum threats. This protects sensitive data keeping it confidential and unaltered. - Achieving crypto agility
Adopting PQC algorithms enhances crypto agility, allowing organizations to smoothly transition between classical and quantum-resistant algorithms as new threats emerge. This flexibility ensures that the system, application, or any other critical asset is designed to adapt agility in cryptographic requirements. - Hybrid Solution
A hybrid solution combines traditional cryptographic algorithms (e.g., RSA) with PQC algorithms to provide backward compatibility within existing systems while introducing quantum readiness. This ensures a smooth transition to post-quantum cryptography without disrupting current operations. - Future-Proofing digital communication
Implementing PQC now prevents attackers from storing encrypted data and decrypting it later when quantum computers become available (“harvest now, decrypt later”). - Compliance with Emerging Standards
Regulatory bodies and industry standards will likely mandate the use of PQC algorithms in the near future. Early adoption ensures compliance and avoids last-minute disruptions.
How can Encryption Consulting help?
Our Encryption Advisory Services offer encryption assessments and encryption audits where we conduct thorough evaluations of your current cryptographic infrastructure to identify vulnerabilities and prepare for emerging quantum threats. This includes assessing digital certificates, cryptographic keys, and overall crypto governance to ensure resilience against evolving risks. Our team develops a customized framework for transitioning to a compliant cryptographic environment that is aligned with industry standards such as NIST, FIPS, and others. We ensure that your organization’s data remains secure while adapting to quantum-resistant technologies. Our strategies are tailored to your organization’s unique security requirements and risk tolerance, helping you stay ahead of security challenges.
Conclusion
Cipher suites are an integral part to the TLS Handshake, telling the client and server how to encrypt their information for the other to understand. The TLS Handshake, which connects a client and server in a secure connection, is used every day to connect to websites, so ensuring it is the most secure it can be is extremely important. Cipher suites are just one way to ensure safe and trusted connections. Code signing, proper certificate management, and secure SSH keys are all other secure connection methods that must also be implemented properly, to ensure the most secure connection to servers.
