In the first part of our series on cryptography, you learned about the data plane, control plane and management planes. The data plane is when all the bits board first class and fly to some exotic location in French Polynesia. The control plane is when impetuous passengers attempt to induce the pilot to fly to the exotic island where all those bits are hanging out. And the Management planes are the rarified jets upper management uses to commute to work from their lofty homes in French Polynesia.

LoL, I’m feeling silly today. Anyway, today you’re going to learn about the differences between symmetric and asymmetric cryptography. I won’t be talking about planes today. If talk about AES and HMAC quicken’s your pulse and makes your pupils dilate then you’re in the right place.

*Dive in your geek.*

## Symmetric Protection

The Caesar Cipher I shared in my previous post is a great example of a Symmetric encryption algorithm. Whenever you hear the word “symmetric” you should think of symmetry or something that is* the same on both sides*.

And that’s exactly what symmetric encryption is. It means both sides; namely, the sender and receiver, have the same encryption key.

In our Ceasar Cipher example the key was a character offset of 3. So anyone with that one key could decrypt our inane message.

An algorithm is just a

process. It’s a methodical way of doing something.

There are several symmetrical algorithms that people use today:

- DES (Data Encryption Standard)
- 3DES (Triple DES, which is actually only
*twice*as strong as DES) - AES (Advanced Encryption Standard)
- IDEA (International Data Encryption Algorithm used with PGP emails)

Symmetric algorithms are faster than their asymmetric cousins so people usually use them to encrypt bulk data being sent back and forth. Asymmetric is usually used for authenticating people and devices.

So let’s talk about the fascinating world of asymmetric encryption.

## Applauding Asymmetric Encryption

Symmetric encryption use the same key for encryption and decryption; conversely, asymmetric technology uses *two keys*. But the perplexing difference is this: **only key1 can encrypt the data and only key2 can decrypt that data**.

Think about that.

You have a key pair but each key is only one part of the equation.

It also works in reverse. If I encrypt a message using **key2** you would need **key1** to decrypt it.

We have a mathematically related pair of keys such that it is virtually impossible to figure out one key from the other.

And if I encrypt something with **key1** and someone stole **key1** he *couldn’t decrypt it with key1*. He would need key2 for decryption.

I don’t know why this is so amazing to me lol

Asymmetric encryption is more secure than symmetric encryption but the increased complexity means it also requires more CPU cycles. In other words, asymmetric encryption affects the Control Plane more than symmetric encryption. *The cost is stronger security at the expense of performance*.

Two common asymmetric algorithms are RSA and DSA.

But what does this look like practically? Let’s look at DSA:

We’ll let’s say you’re a company who sells odor busting socks. Smocksocks is a good name for your company. (check out my 3 part tutorial series on Active Directory for the story behind that name)

And let’s say you want to make sure your employees can securely send HR data containing social security numbers over the internet. How can you ensure the confidentiality of the data? In other words, how can you encrypt it?

You could tell the network administrator to generate key1 and key2. This is called generating a **public/private keypair**. One key is a* public key* known to the world and the other key is a *private key* known only to the person or thing generating it.

On a Mac OS X box or Linux machine you can pull this off by simply typing:

ssh-keygen -t rsa

If you zoom in on the output you can see `ssh-keygen` saved the public key in:

/Users/vhudson/.ssh/id_rsa.pub

and the private key is

/Users/vhudson/.ssh/id_rsa

Note the .ssh folder starts with a period which Linux and Mac treats as a hidden directory but you can still see it by manually typing in the above paths.

So what happens next? How are your employees going to submit their HR information to you? Well, they could print it out and send it via the Postal Service but that’s not very efficient! A better (and smarter) way is this:

You could email your public key to your employees.

Hey everyone,

If you have any HR related information, please encrypt it using our public key. The file id_rsa.pub is attach for your convenience.

Signed, your gracious and kind CEO

Vonnie Hudson

Remember this is the public key so anyone can see it and *that’s the point*. It doesn’t matter if a competitor somehow used Wireshark to capture the packets to steal your public key. The worst he could do is encrypt a message and send it to you. He can’t use it to decrypt anything.

So how do you decrypt the messages encrypted with your public key?

By using your private key!

The only person who can decrypt a message encrypted with your public key is **you** because you’re the only person with that private key.

Of course this assumes you don’t have a Trojan on your computer and no one hacked in and stole the private key. It assumes you have adequate safeguards in place to protect the private key but the point is that the private key is the only thing that can decrypt the message.

## The “i” in CIA

So we’ve addressed confidentiality but now we need to explore integrity. Integrity is all about making sure the data wasn’t changed. How can make sure the data that was sent is *exactly* the same as the data that arrived? Is there a way to do that in cryptography?

Oh yeah!

hahah so check this out.

To make sure that data hasn’t been modified you can use something called **Hashing **and we’ll hash out the details in the next article (pun intended!)

I’m such a word geek haha.