Public-Key Cryptography

The Problem It Solves

If there are two parties that want to communicate in a secure manner, then ideally they would have a shared key to do that communication. But that's not always a possibility, and that's where public key cryptography comes into play, where we use asymmetric keys to do our encryption.

The area that we're looking at is the asymmetric key. Remember, when we talk about symmetric, we've got the same shared key — we call that a pre-shared key — that these two people have so they can communicate back and forth. With asymmetric, we don't have that availability, so we have to come up with other solutions for us to be able to communicate in a secure manner when we have different keys.

Really, the problem is that we don't always have the advantage of being able to pre-share a key. For instance, if you're talking to web servers and you're surfing the web, there are a lot of sites that you visit that you've never visited before, and we need to make sure that you are connecting to it in a secure manner, that there's no man in the middle and you're not creating an account on some sort of hacker's website. So what we need to do is secure this communication, but we don't have the same keys that we can encrypt and decrypt. So how do we handle that?

There are a lot of different ciphers out there that actually can help facilitate this, but the two most popular are Diffie-Hellman and RSA, so those are the ones we're going to look at. The way they function actually is quite a bit different. But essentially we do it through something called a public key. There's a public key that's known to everyone, and a public key can be used to be able to encrypt and decrypt data in certain ways.

What We Use It For

So what are the uses that we would use public key cryptography for? Well, the main purpose is for key exchange, but for some ciphers we could also do encryption, authentication, authenticity, digital signatures, non-repudiation. Those are the use cases that we can actually use these for, once again depending on the cipher.

There are a lot of different ciphers that fall under this public key cryptography; however, we probably want to choose certain ones depending on what we're trying to accomplish. The main ones that we will be focusing on are the Diffie-Hellman key exchange and RSA.

These two ciphers were named by the last name of their creators. So Diffie-Hellman is from Martin Hellman and Whitfield Diffie, and RSA is from Ron Rivest, Adi Shamir and Leonard Adleman. The way that these two ciphers operate is very different from each other, where Diffie-Hellman actually has some shared information and there are two public keys that end up being generated from this, while RSA just has one public key.

Diffie-Hellman

Let's take a deeper dive into what those look like. Our user here wants to access some resources that are on this bank of servers here, and so they need to do it securely — this information can't get out. What needs to happen is they need to exchange a key so that they can communicate back and forth, and they're going to do it using the Diffie-Hellman approach.

So with this, the user is going to be assigned Y, and the web server is going to be assigned W. The user has a private key that only they know about, and no other devices out there know what that private key is. Same thing with the web server: it has its own private key, and no other device knows what it is. Then they're going to agree upon some other values. There's a couple of values that they'll agree upon, but it can be public — anybody can see this and it's not that big of a deal, so they can exchange this back and forth without concern that somebody's going to get that information.

Now what this user does is combine their private key, which is Y, with the shared values, which is S, so they get Ys, and they create a public key, and this public key can be seen by anybody — that's why it's public. Same thing, the web server does the same thing: it takes the W, combines it with the S to create a key that's Ws, and then they now have a public key that can be seen by anyone that's out there.

These two keys are exchanged, so this key gets sent to the web server and this key gets sent to this user. Now they have each other's public keys, and anybody else could have it too — it doesn't matter. This user is going to take the public key that she was given, which is Ws, and combine it with her private key, and we'll end up with a Wsy key. This web server will take the key that it was given, which is Ys, combine it with their key, which is W, and gets a Ysw.

Now, even though these keys — this is a Wsy and this is a Ysw — it goes through a mathematical process as it's doing all of this, which essentially means that these end up with the same value right there. So it's kind of like multiplying: if you multiply letters together, it doesn't matter what order it's done in, you're going to end up with the same answer. So the key is going to be the same. No one else knows about it, because no one else knows what they used to figure it out. And since no one else knows, now they both have the same key that's private, that no one else has seen, and they can use this now to encrypt traffic back and forth.

RSA

RSA works a little differently. It's still built around that there's a private key that no one else has access to — no one should have access to it — and there's a public key, something that you can hand out to anyone. So this web server has both a private key and a public key. What can happen is the public key can encrypt something that a private key can decrypt, or vice versa: a private key can encrypt something that the public key can decrypt.

So what can happen is, if we want to send confidential information — let's say this user wants to send confidential information to this bank of web servers right here — this web server could give this user the public key, and then that user could encrypt a message using that public key, and only this bank of web servers can decrypt it, because they are the only ones that have the private key.

It's pretty interesting what we can do with these public-private key pairs. There are ways we can actually verify identity. So let's say this user wants to verify the identity of the web servers; they can do that through a public-private key here. What this user is going to do is get a hold of the public key — probably not through the source, right, since it's verifying these servers right here, it doesn't want to do it through the source. So if this server sends a message to this user that's encrypted with this private key, this should be the only key that decrypts it. So if the user is able to decrypt that message with this public key right here, then the user will know that it was encrypted with this private key and that this is the proper server that it should be, that this user should be communicating with.

How the Two Compare

Diffie-Hellman and RSA actually do function quite a bit differently, where Diffie-Hellman has two private keys, two public keys and a shared value, and RSA uses one public key and one private key. There are different combinations that RSA can go through depending on what you're trying to do, versus Diffie-Hellman is just really for key exchange, so that once you have the key you can do some sort of encryption after that. But with RSA it can actually perform lots of different functions, depending on what you are trying to do.

One thing I want to point out here is that with Diffie-Hellman it's actually a key exchange — it's actually not technically encryption. If you noticed here, we didn't actually encrypt things with the Diffie-Hellman. What we did with RSA is we encrypted a message with the public key, and then you can decrypt it with the private, or you can encrypt it with the private to decrypt it with the public. But at no point in time have we actually encrypted these keys over here; we've just exchanged them in clear text. So it's a key exchange, and what we have in the end is a key that can be later used for encryption, but the Diffie-Hellman key exchange didn't actually do the encryption.

Now recall the difference between symmetric and asymmetric: that symmetric can be a lot less bits versus asymmetric has to be a lot more bits for the same level of security, and how this really slows down the processing and can be problematic. So a lot of times what we do is we just use this as a key exchange to get two devices talking back and forth in a secure manner, and then what we're going to do is agree upon a shared key that we would do the bulk of our encryption with.

Protocols That Use These Ciphers

So how do we use these ciphers? Of course, we've already mentioned for key exchange, for encryption, for that type of thing. But specifically, what are some examples of protocols that we actually use to implement them? Here's a list of a bunch of protocols, some of them that you might be familiar with: maybe IPsec, perhaps SSL or TLS, perhaps SSH. And remember, protocols are the standards for communications, versus a cipher is a type of algorithm for encrypting data.