Imagine you want to send a secret message to your best friend. You could write it on a piece of paper and put it in an envelope. That’s safe because only your friend can open it.

But if you wrote that message on a postcard and mailed it, anyone who handled the mail could read it. That’s basically what happens on the internet without encryption.

The postcard-era Internet

In the early days of the Internet, sending data was like sending a postcard. The data traveled through the “series of tubes” that is the Internet, but anyone could read it as it made its way to the recipient. This meant that not only could the intended recipient read it, but anyone interested could, too.

For obvious reasons, this wasn’t a good thing. Your Internet Service Provider (ISP) could read the data you were sending, your government could use it to spy on you, and hackers could use it to steal from you. If you were buying a pair of sneakers online, you were sending your credit card number and address in plain text.

Scrambling the signals

Encryption is a mathematical way of scrambling data. It turns readable information (like “my credit card number is 2886-9397-1439-6078, which expires in June 2030 and can be validated using CVV2 403”) into a jumbled mess (like 1b6af07de8634fe6d971ca62e9dabb6c122c9671e24550b847876cd315fded24).

To read the jumbled mess, you need a “key.” Without the key, it is virtually impossible to read the data.

When you see HTTPS or the padlock icon in the address bar of your browser, it means that the website is using encryption. It’s like putting the postcard inside a locked briefcase before sending it.

The digital handshake

You can’t just magically get a secure connection. There’s a process called a “handshake” between your computer and the servers for the website you’re visiting.

1. The request: Your computer asks the website, “can we talk securely?”
2. The ID: The website sends a special certificate back that proves it is who they say they are.
3. The key exchange: Your computer and the website generate a key using some special math (an analogy for which is provided below), and the result is a shared secret.
4. The lock: Now that the key is on both ends, they lock the connection. Everything you send (your password, your search history) are scrambled using that key. Only the two computers at each end can unlock the data.

How can I tell?

You can tell whether a website is using HTTPS or not. While every browser displays it in a different place, it’s normally in or around the address bar (the place where the address for the website is entered).

That padlock and the statement that the connection is secure is your assurance that the website is using HTTPS. You can even investigate the encryption components that were used to exchange keys and make the locks by clicking into the connection details in most web browsers.

The nitty-gritty of key exchange

Heads up! This section gets kind of technical!

We glossed over the “key exchange” portion of the handshake process earlier. Let’s look a little bit closer at the process. From earlier, we know that both of the computers at each end of the connection need to have a key in order to lock (encrypt) and unlock (decrypt) the data. The encryption and decryption keys must be the same on both ends, but how can we transfer the key itself over an unencrypted connection without someone stealing it?

For our example, let’s consider two computers, which we’ll name DIFFIE and HELLMAN. The connection needs to be initiated by one of the computers, and in our example, DIFFIE will initiate the connection by reaching out to HELLMAN and asking whether a secure connection can be set up.

HELLMAN is capable of a secure connection and will respond with its capabilities. The capabilities include, among other things, the options for the encryption/decryption key format. DIFFIE picks from the list of available options.

DIFFIE will generate a code which it will share with HELLMAN. The code is 3434. We’ll call this code the public key. Importantly, not only can HELLMAN read the public key, so can any other computer. However, this won’t matter because of the special sauce we’re about to add.

Now, DIFFIE and HELLMAN will both generate a secret code. DIFFIE generates the secret code 1122, and HELLMAN generates the secret code 3344. This secret code will never leave each computer; HELLMAN won’t know DIFFIE’s secret code, and DIFFIE won’t know HELLMAN’s secret code. We’ll call this secret code the private key.

DIFFIE and HELLMAN will now “add” the shared public key to their respective private keys. DIFFIE ends up with the code 4556, and HELLMAN ends up with the code 6778. Importantly, it’s impossible to definitively reverse this addition process without just guessing all of the combinations. For example, DIFFIE could’ve used 1+4555 or 2+4554 to achieve the same result of 4556. (In the real world, we use much longer and more complex methods to generate these keys to make sure they’re really irreversible functions.)

DIFFIE will send their added code (4556) to HELLMAN, and HELLMAN will send their added code (6778) to DIFFIE.

Now, we’ll add the original private key for each computer to the exchanged added keys. DIFFIE will add their secret code 1122 to the exchanged key 6778, and HELLMAN will add their secret code 3344 to the exchanged key 4556. You might realize now that the resulting numbers are the same: 7900.

Without having to exchange the private key directly, we are able to share it with another computer. This process is called a key exchange, and while it doesn’t guarantee that the other computer is who they really say they are (this is a different process called authentication), it is a fundamental component of how we communicate over the Internet securely.

Fun fact: if you’ve used SSH or SFTP and gotten a public key fingerprint prompt (something along the lines of “The authenticity of the host…can’t be established. ED25519 key fingerprint is SHA256:…Are you sure you want to continue connecting?”), this is the authentication process that establishes you’re sharing the public key with the right computer. The actual key exchange itself occurs using that public key sharing technique we just examined. The implementation of most key exchanges for SSH and SFTP is called Diffie-Hellman key exchange (hence our example names).

You can see the public portion of the key used to encrypt this webpage by looking for the padlock, then looking at the details. The certificate is used for the authentication step, while the public key is the very same concept that’s demonstrated here. (They’re actually hashes of the actual keys, but the concept still stands.)

Further reading

R.L. Rivest, A. Shamir, and L. Adleman. A method for obtaining digital signatures and public-key cryptosystems. Communications of the ACM, vol. 21, iss. 2. February 1, 1978. [Online.] Available: https://doi.org/10.1145/359340.359342.