Crypto Hypno: Cryptography basics (Part 4 of 5)

If you’ve been following this series from its infancy, you should already know the basics of encryption, symmetric/asymmetric encryption, and message hashing.  Today we’re going to tie everything together in tidy little bow.  You’ll learn about the two primary ways we can employ to exchange encryption keys.  We’ll also dip our toes in the warm waters of Virtual Private Networks. (VPNs)

I live for this stuff man!  Let’s go!

So let’s do a quick review of symmetric and asymmetric encryption.  These two are popular contraries so we need to iron out the differences:

• Symmetric encryption uses a single key, also known as a session key, to turn a plaintext message into encrypted text known as ciphertext.  The same key encrypts and decrypts.
• Asymmetric encryption uses a pair of similar but unique keys.  The keys are mathematically designed to work together but they are completely different.  One key is private and never shared with anyone and the other one is public and can be shared with everyone. (including hackers)  The premise of asymmetric encryption is that encrypting something with a private key can be decrypted with the public key.  Similarly, if you encrypt something with a public key you can use the private key to decrypt it.

Let’s say you need to make a secure online transaction with your bank over the internet.  How does this really work?

Do you know?  We’ll you will in a few minutes!  Get comfortable.  Strip down to your boxers or PJ’s, put on some Barry White and read with me.  We’re going deep haha.

---

Asymmetric stuff in the real world

When you got to https://www.bankofamerica.com you end up getting a public key that was issued to the Bank of America.  I’ll talk about how you actually get that public key later but now I just want you to realize that the HTTPS/SSL/TLS resource you access over the web gives you its public key.

So if you want to login to the bank, you obviously don’t want your credentials floating through the treacherous waters of the internet in the clear.  So what happens?

Well you could encrypt your username and password using your banks public key.  Then the bank could use its private key to decrypt your credentials.

But that’s not the only pertinent example.  Maybe after logging into your bank you want to send a secure email to your boss.  You could take your bosses public key to encrypt the email into ciphertext and then your boss would decrypt it with his private key.

Another really good reason to use asymmetric encryption is when you want to validate the sender.   Let’s go back to the bank example. (because I like money haha)

Let’s say your bank wanted to send you a secure message that they deposited an extra $1,000 in your checking account because you’ve been a loyal member for 10 years.  But the bank wants to make sure you know the message originated from The Bank of America and not someone else.  The bank could include its digital signature with the message.

I covered digital signatures in the second series, but I won’t make you click through a bunch of links to find that.

Digital Signatures work like this:

You take some juicy data and feed it through a hungry hashing algorithm which poops out a the result called a digest.

Then the bank encrypts the hash with its private key.  The act of encrypting the hash with a private key is a signature because the encryptor is the sole owner of the private key and therefore proves he’s the one who “signed” the hash.

Next, the bank would send the encrypted hash along with its message to you.  You could then decrypt the encrypted hash with the banks public key.  This proves the message really came from the bank.

How?  Because the bank is the only one with the corresponding private key!

Handling those pesky keys

So how do we get the public keys to the right place?  Should the bank just send you an email with a public key attachment?  Should your bank send you a certified letter via the US Postal Service that includes a paper document with the public key written on it?

We’ll there are two methods of key exchange

• In band
• Out of Band

In-band means you and the CEO of the Bank of America join a rock band and go on tour selling albums about money orders and checks. Hahaha.

Man I’m such a dork.  But who cares.  You can hate me.  It won’t mind lol.

With an In-band public key send, the bank would hand over a Digital Certificate within a HTTPS session.  In other words, when you entered https://www.bankofamerica.com, your browser would furtively download a small text file that includes a bunch of identifying data about the bank including its public key.  This is actually part of a bigger process called Public Key Infrastructure (PKI) but I won’t mess with that in this guide. We’ll finish up this cryptography week tomorrow with PKI.

Another option is to use something like a VPN connection to transfer the keys.  You could initiate a VPN connection to the server.

Here’s how it works:

Vonnie on VPN

Have you heard of IPSec?  Do you know what IPSec does for a living?  IPSec is the theme song of VPN.  It provides confidentiality through encryption, integrity through hashing and authentication through passwords and certificates.  IPSec also counts packets so if someone tries to replay an previously sent pack it says “Hey, you already sent packet #100 so I’m not going to let you send that again”.  This is called anti-replay protection.

So check out my beautiful artwork.

The big fluffy blue thing is the cloud.  The interwebs!

The black soft balls are the routers (okay that didn’t sound right)

and the smiling computers on the end are your computers. duh.

I also slapped on the 10.0.0.0/24 network as the inside trusted LAN for R1.  192.168.0.0/24 is the inside LAN at the remote site.  And the 2.0.0.1/16 and 3.0.0.1/16 IP addresses are the public interfaces for R1 and R2 respectively.  The green gooey line indicates the direction of data flow.

---

By the way, if IP addresses make you feel a little uncomfortable (especially that slash 24 thing) then go through my series on IP addresses.  You’ll be an IP addressing pro after you read that thing so check it out.

---

So we have these two routers R1 and R2.  How would we setup a VPN tunnel? More specifically a Site-to-Site VPN?

IPSec actually has two logical connections between both routers.  There are two tunnels between two VPN gateways.

Two VPN peers, R1 and R2 in this example, go through two phases to build these tunnels.

• IKE Phase 1
• IKE Phase 2

IKE Phase 1

First R1 and R2 use an IKE Phase 1 tunnel to tell each other the secrets they’ll use for the communication channel.  Then PC1 and PC2 use an IKE Phase 2 tunnel to actually send the traffic to each other.  Phase 2 is also called the IPSec Tunnel.

Routers chat over the IKE Phase 1 tunnel and the user traffic is sent over IKE Phase 2 tunnels

Most people don’t realize this!  So you’re already a step ahead of the pack.

So when R1 receives VPN traffic from Dora he whines:

I don’t have any tunnels! I neither have an IKE Phase 1 tunnel nor an IKE Phase 2 tunnel! There’s no security association in place!  Whaa! Whaa! hahaha.

So R1 builds the IKE Phase 1 tunnel by sending R2 all it’s IKE Phase 1 policies.  It negotiates:

• Hashing (“I can do MD5 and SHA, what about you R2?”)
• Authentication (“I can use Pre-shared keys and RSA signatures”)
• Group (“I can use Diffie-Hellman numbers 1, 2, 5 and 7”)
• Lifetime (“Hey R2, here’s how long this tunnel can stay up”)
• Encryption (“I can use DES, 3DES and AES! What about you buddy?”)

By the way Diffie-Hellman (DH) is the algorithm that allows two devices to establish a shared secret key.

So R2 responds with its compatible set of compatible options and continues on its way.

Once R1 and R2 agree to the DH group they use it to create the keys and then they used the agreed upon authentication method to authenticate each peer.

And that’s IKE Phase 1.

---

Now we have a security association (a tunnel) between both routers.  By the way, this can happen in main mode or aggressive mode. Main mode uses more packets than aggressive mode but they both do the same thing.

---

IKE Phase 2

In IKE Phase 2, we’re negotiating the hashing, DH group, lifetime (for example, after every 200MB the tunnel closes and has to be regenerated) and encryption that the computers will use to communicate with each other.

Phase 1 is for routers Phase 2 is for computers.

Also during IKE Phase 2 the computers may agree to use PFS (Perfect Forward Secrecy).  This just means the key that came from the womb of DH in IKE Phase 1 is completely regenerated in IKE Phase 2.  This makes it more secure at the cost of performance.

Then with the IKE Phase 2 tunnel in place, the IPSec tunnel is in place and both parties can securely exchange data.

Wow, I just explained VPN hahaha.

The Bottom Line

You know that song by P. Diddy called “It’s all about the Benjamin’s baby”?  Well, the theme song of cryptography is “It’s all about the cryptokeys baby”.

Now what y’all wanna do?  Wanna be hackers and file crackers?  Brawlers who be dippin in the benz with the spoilers.  hahaha.

In the next article you’ll learn about a non-repudiation, the difference between block and stream ciphers and the glorious world of public key infrastructure. (PKI)  It’s going to be a wild ride.

Saddle up partner.