How does website or VPN encryption work?

You’re mostly right, but you’re also overlooking an important step in that process. How do you exchange that encryption key securely before the encryption has been set up?

In other words, how do you send someone a password securely if the only thing that they would have to make it secure is knowing that password before they got it?

The problem is that you need to encrypt to exchange data securely, but you can’t encrypt until you’ve exchanged the encryption key. It’s a classic chicken and egg problem.

Let me explain what happens here at a very high level.

Public key encryption

Normal encryption, the kind you’re probably most used to, is where you have one key. That key is typically a password or something derived or calculated from a password. When you use it to encrypt something the recipient who wants to access it must know that same password or key and uses it to decrypt the encryption.

Public key encryption is different.

Instead of a single encryption key, a key pair is generated. That pair or keys has a very interesting property: anything encrypted with the first key can only be decrypted by the second, and anything encrypted by the second key can only be decrypted by the first.

I’ll just call it all mathematical magic, because unless you’re a computer scientist or mathematician, it pretty much is. It’s very complex math, and honestly, very cool stuff if you think about it. It’s one of those wonderful fundamental discoveries that actually enables a bunch of the security that we use and rely on today on the internet.

Using public key encryption

While the math is hard, using public key encryption is actually pretty simple:

• Create a key pair
• Make one of the keys public – anyone can see it.
• Keep the other one secret – only you can see it.

That way two things are possible:

• Anyone can encrypt something using your public key that only you can decrypt using your private key.
• Someone can verify that something came from you if they can decrypt it using your public key – because only you could have encrypted it with the matching private key.

It’s that first one that we’ll use to clarify how https and VPNs work.

Setting up an encrypted connection

When you contact a site using SSL (the secure part of https and most VPNs), the first thing that site responds with its public key.1

Your browser can then generate a completely random number – typically a fairly large one. It encrypts that random number using the public key of the site and sends the encrypted data to the site. The site then decrypts this random number, as only it can since it has the secret, private key that matches the public key that was used to encrypt it in the first place.

That random number is thereafter used as a simple “both sides need to know it” key for encrypting and decrypting the data that goes back and forth. This simple key is used rather than continuing to use the public/private key pair because it’s simpler and often much faster to actually use. Much like a strong password this simple key is often very large making cracking it effectively impossible.2

Wifi Encryption

It’s important to realize that when you place encryption on a Wifi router – for example by enabling WPA2 and requiring a password – you’re only encrypting the conversation between your router and your computer, nothing more:

As it turns out, if you do your banking or VPN as https over a password-protected Wi-Fi, you’re actually encrypting twice while you’re on that wireless connection:

Once, for the connection between your computer and your WiFi access point, and once for the entire connection between your computer and the service to which you are connected.

That’s OK. The SSL connection ensures that you’re encrypted from one end to the to other – that’s its job. That the wireless leg of that conversation is being encrypted again causes no harm whatsoever.