So let's discuss SSL encryption algorithms for the moment. If you are using Chrome, you've got a choice between AES, Triple-DES, and ChaCha20. This pic shows the list that Chrome sends to web servers saying which algorithms it'll support.

Yes, Triple-DES is an option.

DES was the algorithm first standardized in 1977 that was then successfully cracked with Deep Crack in 1998, because it has only a 56-bit key that can be easily brute-forced (guessing all possible keys) by modern desktop computers.

Triple-DES is the idea that we'll just encrypt* it three-times, with three separate keys. This effectively doubles the key-length to 112-bits, which is beyond the ability of modern computers to crack.

By comparison, bitcoin mining solves a 65-bit key every second, which is probably the largest brute-force cracking capability out there right now. So we know Triple-DES is secure for the moment.

But is it fast? I used the openssl command-line utility to encrypt a 100-megabyte file to benchmark performance. Triple-DES is roughly 100 times slower than AES.

That's a somewhat unfair comparison. The reason is that modern CPU all support AES acceleration, whereas DES/Triple-DES is notoriously inefficient in software, requiring hardware acceleration that doesn't exist in modern hardware.

The third algorithm in that list at the top is ChaCha20. It doesn't have hardware acceleration, either, but the algorithm is specifically designed to be efficient on modern CPUs. In software, it's only about half as fast as AES's hardware acceleration.

Though that's an unfair way of describing it. It's specifically exploiting the SSE/AVX instructions in x86 CPUs, so is essentially hardware accelerated.

Anyway, the server comes back and tells me that, among the options, it's chosen TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. What do all those parts mean?

The first part is the protocol, that it's using TLS 1.x rather than the older SSL 3.x protocol. That's the norm these days, older SSL versions are no longer allowed, because of weaknesses.

The next part is ECDHE, which governs the "key exchange" part of SSL, where the client/server generate a random AES bulk-encryption key and exchange it with each other, across the public medium.

In the past, they'd just use the public-keys from the certificates to exchange the AES bulk encryption key, but that meant an attacker could sniff the wire, save the packets, and then possibly years in the future crack/steal the certificate's private-key, and decrypt the session.

With ephemeral diffie-hellman, uniquely generated public keys are used, and then discarded soon after. The certificate's key only signs this transaction, so if it's later compromised, this connection isn't. This is known as "forward secrecy".

Now that we are done with key exchange, we have to sign it with the certificate. In this example, we are using RSA, with long 2048 bit keys. Other options are to use ECSA (elliptical curve signatures), which have shorter 256 bit keys.

In the past, SSL TLS v1.2 and below, they'd send the certificates first, then exchange keys, so we could see the certificate in the packets. With SSL TLS v1.3, they exchange keys first, then send the certificates to verify the connection, so we can't see it in the packets.

So anyway, now we move onto the bulk encryption algorithm, AES, that started this discussion. The first choice is key size, which in this example is 128-bits. It could've chosen 256 bit keys instead.

Both are secure TODAY, but with 128-bit keys and Moore's Law, we can capture the packets today and in 100 years be able to brute-force decrypt them. That day may come sooner with quantum computers.

The next part in the equation is "GCM". This is two things: both the 'mode' in which AES operates, and also how the authenticity is maintained.

AES is a "block-cipher", which means for the same key, two different blocks containing the same data will be encrypted the same. Why this is bad is demonstrated with the ECB penguin, an encrypted image that still shows a penguin.

So we what we do here instead is use "counter-mode", where we encrypt each block differently by including a counter (0,1,2,3,...) in the encryption process for each block.

Another issue that needs to be solved is the fact that an adversary can change the data and not be detected. This will result in gibberish when decrypted, so the attacker can't control how the result, but often gibberish is enough for a successful attack.

Therefore, we need to 'hash' the data along with encryption. That's combined with the counter mode in an algorithm called "Galois Counter Mode", hence GCM. Each packet includes an extra few bytes to verify that none of them have been maliciously changed.

The last bit, SHA256, is a hash algorithm, but isn't how it's hashing packets. Instead, this last little bit is about some internal housekeeping that's a little complicated even for these tweets, so I'm going to skip it.

Anyway, we see that SSL is about a lot of different choices, we have a whole suite of them to choose from.
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

Another issue that needs to be solved is the fact that an adversary can change the data and not be detected. This will result in gibberish when decrypted, so the attacker can't control how the result, but often gibberish is enough for a successful attack.

Therefore, we need to 'hash' the data along with encryption. That's combined with the counter mode in an algorithm called "Galois Counter Mode", hence GCM. Each packet includes an extra few bytes to verify that none of them have been maliciously changed.

The last bit, SHA256, is a hash algorithm, but isn't how it's hashing packets. Instead, this last little bit is about some internal housekeeping that's a little complicated even for these tweets, so I'm going to skip it.

Anyway, we see that SSL is about a lot of different choices, we have a whole suite of them to choose from.
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256