If you study SSL and encryption long enough, eventually you’re going to come across the word “cipher.” Aside from just generally being a cool word, ciphers are a very important part of encryption.
So, what are encryption ciphers?
Ciphers are algorithms, more specifically they’re a set of steps for both performing encryption as well as the corresponding decryption. Nowadays ciphers are dependent upon the advanced processing capabilities of computers. That hasn’t always been the case though. One of the first, well-known historical ciphers belonged to Caesar – emperor of Rome and purveyor of fancy appetizer salads – who used it to communicate with his generals during military operations.
Over the years, ciphers have become more complex, but the logic behind them has stayed the same. Whether it was Caesar crossing the Rubicon, the infamous Enigma cipher of World War II or some of the algorithms of today—the idea has always been to encode or encipher a message in such a way that only the intended party can read it.
For all intents and purposes, when we discuss ciphers as they relate specifically to SSL encryption, there are two kinds of algorithms: symmetric and asymmetric. This really comes down to the kind of encryption you’re going to be performing, again, symmetric or asymmetric.
Symmetric encryption involves two keys that are the same, or as the name quite cleverly implies, symmetric. Both keys can perform both functions: encryption and decryption. You see this during an encrypted web connection between a browser and a server. After the SSL certificate has been authenticated and the SSL handshake is complete, the browser and server exchange symmetric “session keys” that allow them to communicate securely for the duration of the visit. While these session keys are in play, they are making use of a symmetric cipher.
Conversely, with asymmetric encryption, you are talking about different keys with different abilities. The most obvious example of this is the public/private key pair that is used during the SSL handshake. In this scenario, one key encrypts and the other key decrypts. This kind of encryption requires a different kind of cipher—an asymmetric algorithm.
There are many different ciphers that are commonly used in encryption, often in conjunction with one another. That’s because, specifically as it relates to SSL, you’re not using just a single algorithm but rather a set of algorithms that are grouped together in what is referred to as a “Cipher Suite.”
We’re building towards that concept, so we’ll get there in a little bit. But, now that we’ve got an understanding of the two types of algorithm – symmetric and asymmetric – we can look at some of the different ciphers and the functions they server—then we’ll talk about building a cipher suite.
Here are some examples of ciphers and other similar algorithms:
RSA
RSA is named after the gentlemen that created it: Rivest, Shamir and Adleman. This is a fairly common asymmetric cryptosystem that uses prime numbers and has a wide range of applications.
Diffie-Hellman
Named after Whitfield Diffie and Martin Hellman, this is a public key protocol used primarily for exchanging cryptographic keys over public channels. Prior to methods like DH, keys had to be transmitted in physical form.
Elliptic Curve Diffie-Hellman
A key agreement protocol that gives two parties with elliptic curve public-private key pairs to establish a shared secret (used either directly as a key or to derive one) securely over a public channel.
PSK
Typically written as TLS-PSK, this is a cipher that provides secure communication based on pre-shared symmetric keys exchanged between parties in advance.
AES
Advanced Encryption Standard, a.k.a. Rijndael, is an NIST approved encryption cipher with a block size of 128 bit, and symmetric keys with lengths of either 128, 192 or 256 bits.
Camellia
A symmetric key block cipher with similar capabilities and key sizes to AES. It was developed in Japan by NTT and Mitsubishi and is approved by the ISO/IEC, EU and the Japanese CRYPTREC project.
ARIA
Another block cipher that is similar to AES, ARIA was developed by a group of researchers in South Korea in 2003.
Hash-Based Message Authentication Code (HMAC)
This is a type of message authentication that uses cryptographic hashes to both authenticate a message and ensure data integrity, think SHA-256.
Authenticated Encryption
AE or AEAD provides confidentiality, integrity and authentication assurances on data under a single programming interface. Typically used in conjunction with a block cipher.
Obviously, this is an incomplete list, there are dozens of other ciphers. But this should at least give you some more context when we begin discussing cipher suites in the next section.
A Cipher Suite is a combination of algorithms used to negotiate security settings during the SSL/TLS handshake. After the ClientHello and ServerHello messages are exchanged, the client sends a prioritized list of cipher suites it supports. The server then responds with the cipher suite it has selected from the list.
Cipher suites are named combinations of:
So, for instance, here’s an example of a cipher suite:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
I’ve color-coated it to help you distinguish between the ciphers.
Starting with TLS_ECDHE_RSA we can see that during the handshake, the keys will be generated using RSA and exchanged via ephemeral Elliptic Curve Diffie Hellman (ECDHE). It’s going to encrypt with 128-bit AES using Galois/Counter Mode as its mode of operation and it will employ SHA-256 as its hashing algorithm.
Most browsers and servers have a list of cipher suites that they support, the two will compare the lists – in order of priority – against one another during the handshake in order to determine the security settings that will be used.
Of course, as TLS 1.3 inches towards a final release, this is all going to change. While previous versions of SSL/TLS through TLS 1.2 used the version of cipher suites described here, in version 1.3 cipher suites will change structure as they will only be used to negotiate encryption and HMAC algorithms.
Because the structure of 1.3 cipher suites is different from its predecessors’, they will not be interchangeable with older TLS versions.
For those that like to skim, here are the key takeaways from today’s conversation:
