SSL/TLS: What’s in a key?

Introduction

SSL/TLS is the foundation of cryptography for computer systems. The reason it has proven so popular and persistent is that it is agnostic of the protocol being encrypted. Originally, security wasn’t on everyone’s mind the way it is today. It makes sense – protocols like HTTP and SMTP were around in some incarnation or another back when only governments and some large universities even had access to what was the precursor to the internet. SSL/TLS “wraps” other protocols such that they occur over a secure channel forged across an insecure network.

“https” by Sean MacEntee is licensed under CC-BY 2.0

How does it work?

SSL/TLS is the perfect marriage of symmetric and asymmetric cryptography. In symmetric cryptography, the same key is used by both parties to encrypt plaintext into ciphertext and decrypt that ciphertext back into plaintext. Ergo, only those with the key can read the message. The major downside here though is that you can’t uniquely identify each individual party in the communication since they’re in possession of the same key. With asymmetric cryptography, each party has two keys: a public and a private key. These keys are intrinsically and mathematically linked such that only the private key can decrypt messages that have been encrypted with the public key, and vice versa. When you visit a website using SSL/TLS, an SSL/TLS channel is formed with the intention of speaking the HTTP protocol over that channel. (But any plain text protocol could theoretically be sent – in fact, you can directly wrap a TCP endpoint in SSL/TLS and not even specify the protocol!). First, your client reads the public key from the x509 certificate being broadcast by the website. The web server on the other end has exclusive access to the corresponding private key. The client and the server then begin their handshake. For our purposes today, we are focused only on encryption, so we will assume the certificate is self-signed and trusted directly in the root certificate store of the client’s browser. (In reality, though, this certificate will most likely be signed by a publicly trusted authority, like https://www.ssltrust.com.au/). The client will establish a secure channel with the server using asymmetric cryptography. The sole purpose of this initial channel is so that the client and the server can agree upon a symmetric key to use for the rest of the communication. It is in this way that symmetric cryptography and asymmetric cryptography are “chained” together to provide the best of both worlds. Now, the communication has a key unique to
each party, but takes advantage of the fact that symmetric cryptography is much, much faster.

It’s all about the inputs

SSL/TLS supports a number of “ciphers” that accomplish different parts of the secure transaction in different ways. One of the things determined by the cipher (negotiated by the client and server during its handshake) is the key generation algorithm. The key chosen is extremely important, because it has implications for both security and performance. In order to generate asymmetric keys, for a very long time, the reigning champion was RSA. RSA takes advantage of prime numbers and one-way functions (similar to those used in hashing) to easily compute a keyset that is impossible to calculate in reverse without brute forcing every possible combination of keys in the keyspace against the private key. This is what makes the key size selected so important. Today, when using RSA, a key size of 2048 is considered to be reasonably secure. Until recently, a key size of 1024 was considered secure for most purposes, but as hardware has gotten better, keys of this size can be brute forced by those with enough money to buy a lot of hardware (like nation-states). The larger the key size, the slower the performance of the RSA algorithm and the more CPU cycles on the server side this key generation consumes.

RSA vs. ECC

A more modern (but by nature less commonly supported) way to generate keys is something called Elliptic Curve Cryptography (ECC). ECC is an umbrella term that describes ECDHE (a key establishment protocol) and ECDSA (an authentication protocol). RSA refers to the algorithm suite encompassing both key exchange and digital signatures. It is ECDSA that is in a direct analog to RSA key generation. (ECDHE is the ECC suite’s answer to Diffie-Hellman Ephemeral (DHE) which is used by some ciphers to constantly rotate the symmetric key in use to thwart attackers who have already
compromised the private key either now or in the future.)
ECDSA works by taking advantage of the mathematical properties of circles, parabolas, and hyperbolas to allow for secure communication using shorter key lengths. A major downside of ECDSA though, is that it relies extremely heavily on high-quality entropy. If the random numbers selected as inputs for the algorithm can be guessed, the security of the algorithm falls apart. In many Linux based systems, entropy is derived from two virtual devices: /dev/random and /dev/urandom. /dev/random is a blocking device for generating this randomness. It calculates randomness based on system activity like
keyboard and mouse input. If the system does not have enough information to give the level of randomness required, it actually makes the program wait indefinitely for a response. The program will then have to decide how to proceed. /dev/urandom, on the other hand, prioritizes performance over security and will return a result, even if the randomness is of lower quality. (https://linux.die.net/man/4/urandom) It is extremely important for an ECDSA system to never be based
on lesser quality randomness. RSA, in contrast, is based on the factorization of prime numbers, which is why high-quality entropy is not required.

Which is better for you?

RSA is not broken and is extremely compatible. It has been used for a long time, and newer implementations aren’t coming out left and right. For example, ED25519 (https://ed25519.cr.yp.to/) is yet another algorithm for key generation based on ECDSA that promises to address some of its weaknesses. By all accounts, it really is much better suited for cryptographic purposes, but yet another we have to wait for libraries and systems (historically slow to adopt new standards, and for good reason) to provide a level of compatibility that it makes sense to even attempt to support. Organizations like Cloudflare or Google that need to benefit from the economy of scale might consider trying to eke out every bit of performance possible. For most companies though, RSA is probably still the safer bet as of today, both from a security standpoint and from an ease of management standpoint. It is, however, worth staying up to date on technologies at the periphery of practical use. Most devices today are extremely powerful, but if you are working on a device in an emerging market based on older hardware, or embedded systems that require a low energy profile, ECC based cryptography is an excellent choice.