# Public Key Infrastructure Part 1 - Cryptography

## Table of Contents

*UPDATE:*

## Introduction #

In my openssl certificate command blog, I listed out common commands for dealing with certificates using openssl. I was doing some TLS for my work and had to learn the PKI. I wished I had learned it sooner. Security as a concept has always scared me because I always thought you need strong math skills. Although it is true, understanding the concept is not hard.

The goal for me is to write a blog series about PKI and solidify my own understanding. By doing so, hopefully I can help others understand the power and importance of PKI. This is the first part and I will be separating the topics into small digestible blogs.

## What is it? #

There is no single definition of a Public Key Infrastructure, but a PKI is build on top a lot of other concept, cryptography, certificates, CA, RA, etc. To illustrate the concept, I have to start with the basics and I find it easier to use them in examples. Explaining it in a way that will tell how it works and why it is needed. As is it’s the standard in all CS concept blogs, the old Alice and Bob tale. I will try to make it fun and exciting to read.

## Act 1 #

*Alice* ๐ฉ and *Bob* ๐ง are in love with each other and they live far away from each other. The only way they can talk to each other is by mail. The evil mail man *Chad* ๐ is jealous of them, so he is trying to break the their relationship.

If they write each other letters, *Chad* can easily open it up, read it, and seal it in a new envelope as if nothing has happened. When they receive the letters, they can’t know if *Chad* has tampered with it.

### Scene 1 - Cryptography #

To solve this problem, *Alice* and *Bob* turn their hope to cryptography. They want to encrypt their letters so that other people can read it but cannot understand it. The steps are as follow:

- The sender converts the plaintext message to ciphertext. This step is called
**encryption** - The ciphertext is transmitted to the receiver
- The receiver converts the ciphertext back to a plaintext message. The step is called
**decryption**

Cryptography techniques are usually composed with **key(s)** and **mathematical algorithm(s)**. I am not a math expert, I don’t understand the implementation details. All I care about is the end goal, one can encrypt a message with a key and someone else can decrypt only if they also have the same key. The encryption should be 1-way encryption, meaning it is impossible or nearly impossible to revert the encryption process without the key.

The key should be held privately and securely. Otherwise, if someone else can steal the key, the encryption is compromised.

### Scene 2 - Symmetric Cryptography #

One type of algorithm is **“symmetric cryptography”**. The principal idea is that the same key is used to encrypt and decrypt the message. The end parties both have the same secret key.

Back to the love story, *Alice* and *Bob* agree on a key and start communicating. Now *Chad* cannot understand the letter even if he can secretly view it. Does this solve their problem? Yes, it does!

**But**how do they agree on the key? Can they send their key through letters again? Not really, because there is a chance that

*Chad*, the mailman, can steal the key. One way is to solve this is that

*Alice*and

*Bob*can meet up and agree on a key.

### Scene 3 - Asymmetric Cryptography #

We have a new problem now: exchange the key in a secure manner.

Exchanging key physically is an inconvenient and not practical way of exchanging the key. Sometimes it is physically impossible. They need a secure way to exchange the key. They can’t establish secure communication without a key. This is the chicken and egg problem.

To safely communicate an encryption key, the other type of algorithm is **“asymmetric cryptography”**. The principal idea being that you generate two keys:

- A public key
- A private key

As the name suggests, the public key can be distributed and shared to the public (everyone). The private key is kept securely locally. If someone gets the hold of the public, they can’t do anything with it. One cool thing about asymmetric crypto is that a message encrypted by public key can only be decrypted by the private key, vise versa.

How does having 2 keys solve the problem? Now *Alice* and *Bob* never have to meet up, they can just send their own public keys to each other, then only the other person can decrypt the messages. People can share their public keys on the internet, at the end of an email, anywhere. It is meant to be shared.

Let’s go back to the love story. *Alice* and *Bob* create their own key pairs. Now, let’s try again.

*Alice*encrypts the letter with*Bob*’s public key- She sends the ciphertext to
*Bob* *Bob*receives the ciphertext and decrypts with his' private key.- <…>

Now, *Alice* can be mathematically sure that only *Bob* can decrypt the message, because she encrypted it with his public key. If *Chad* steals the message, he cannot decrypt it. Perfect!

Problem solved? Almost. In a perfect world, this would work and nobody can understand what they are talking about. The message will all be garbage. In the real world, there is a very serious problem.

โ ๏ธ How does *Bob* know that the message is encrypted by *Alice*? He can only be sure that the message is encrypted using his public key. But this can be done by anyone. The public key is shared. Imagine *Chad* impersonating *Alice*. He tosses out her encrypted letter and encrypts a bad message to *Bob*. Their relationship can be in jeopardy.

### Scene 4 - Asymmetric Cryptography Part 2 #

The best way to solve this is to use 2 keys to encrypt the message. Let’s refresh about how the asymmetric keys work. If a message is encrypted by public key, only private key can decrypt it, **vise versa**. Someone can encrypt using the private key and everyone else can decrypt the message with the public key.

On the surface, this seems useless because everyone can decrypt and the message will never be secure. If a message can be *decrypted* by my public key, it means that I am the owner of the private key. Mathematically proven that I am the owner of the key pair. This can prove the identity of the sender.

Let’s go back to the story again.

*Alice*encrypt the first couple words with her private key*Alice*encrypts the letter and the encryption from step 1. with*Bob*’s public key- <… Sends the letter …>
*Bob*decrypts the letter with his own private key.*Bob*also decrypts the encryption using*Alice*’s public key.- If the decrypted result matches up with the first couple words, then
*Bob*can be certain the message is sent from*Alice*.

After all this trouble, *Alice* and *Bob* can now talk in secret and they live happily ever after.

## Summary #

In this blog, I have described symmetric and asymmetric cryptography, why they are needed, and their use cases. Please note that I am **not** saying that symmetric cryptography is bad, because we can’t share the key easily. I am only describing it as not the right tool for the job (establishing a secure connection). In fact, most of the messages exchanged over the internet are using symmetric cryptography once we have established a secure connection because it is much faster.

Cryptography is an amazing and simple concept. The actual math is complicated, for sure, but I donโt need to understand it to appreciate its value.

I have dismissed where people would store the public key and others can be ensured that they have not been tampered with. By publishing the keys online, we would have to do it by an insecure measure. Like the scene 2’s problem. They have services like this keyserver.ubuntu.com or keyserver.pgp.com.

In the next blog, I will explain how we can take this concept and apply to computers instead of humans.