0:04

Hi, folks, Ed here. I'm going to take you through the basics of cryptography now.

Now, we've gone through securID,

we've gone through S Key, we've gone through Kerberos,

you've seen a lot of these things in action.

I've shown you notation without even explaining it to you.

We've popped it up on the screen and gotten you sort of

comfortable seeing squiggly braces and

something inside and a little subscript next to

the squiggly brace and you may or may not think,

wow, they're just assuming, I get that.

I'm assuming that you're sort of absorbing that.

But now I'm going to take you back. I always like doing this.

I've been teaching cybersecurity for 30 years and

I've learned that if you start with the basics,

people don't get it.

But if you start with showing them stuff and just assuming they're getting

it and just assuming and showing them the fun of Kerberos and get them through.

And then once they've seen a bunch, they say, Hey,

why don't we back up and let me show you some of the things we've been looking at?

I found that to be a more effective means of explaining cryptography which,

like I said, I've been doing for three decades.

I bet half of you weren't even

born when I started trying to explain these basics to people.

So, trust me, I think this is the way to go.

Now, cryptography is secret writing.

It's trying to come up with a cookie crazy way for me to communicate with

you and have others that we don't trust unable to hear or understand what we're doing.

It's that simple. And that the way you decipher what I encrypt,

is that you have a special secret or equipment or software,

something we agree on that we assume intruders or outsiders don't have access to.

That's cryptography. That's how it works.

And you try to make it hard but you want to make sure it's

computationally difficult so it's not obvious for somebody to pick up on what's going on.

And you also want to make sure that it's not possible for them to use

brute force tactics to guess every possible thing we would be saying.

And for speech, that's ridiculous.

But you could imagine that for certain types of messages,

the input domain might be small, people can guess it.

Turns out, there's five components to a crypto system.

As a computer scientist,

we've laid out set of plain text,

that stuff you understand,

set a corresponding cipher text,

that's stuff you don't understand.

There's an encryption function that takes plain to cipher.

There's a decryption function that takes cipher to plane and there's a set of keys.

So, those are the five components.

A nice way to kind of think about it is using

the bit-wise XOR function which a lot of you are probably familiar with.

XOR checks to see whether zeros and ones are different.

So, if a zero or one are different than 0 XOR 1 is 1.

It checks, it's 1 when they're different.

It's the same, they're the same.

You can sketch out a plain text series of zeros and ones as

input and then some random key which punches zeros and ones,

take the XOR bit-wise to produce

the ciphertext that you would presumably send over the internet.

Then that ciphertext, you can decrypt

the same XOR with the original key and you get back the original function.

It's kind of a nice way of illustrating plain text key

encryption to cipher text key decryption back to original plain text.

It's a nice way to illustrate the concept.

Now, notationally, you can almost come up with anything you want but

the standard notations are either to put a capital E for

encrypt and then parentheses P and similar,

decrypt using capital D,

but that's not as cool.

I'm more hip to use notation that's not so obvious.

So, I tend to use squiggly braces for both encryption and decryption depending on

the context and we use subscripts next to the squiggly braces to denote keys.

Now, conventional cryptography is symmetric in the sense that we're

using one key or at least the ability to

derive one key from another to do encryption-decryption.

For our purposes, we're just going to assume I have

one key and I'm going to encrypt or decrypt with that key.

Imagine encrypting is walking to the right.

So, if I go boom,

boom, two steps to the right,

stepping to the right is the encryption,

the key is two.

Now, if decryption is stepping to the left and I go boom, boom,

and I step back to my original spot,

the decryption is stepping to the left, the key is two.

In some twisted sort of way,

you can imagine if you didn't know two is the key and I walk over there somewhere,

you don't know how to get back because you don't know

how many steps, you don't know the key.

That's how to think about this.

Now, the basic schema,

the architecture for encryption-decryption for conventional cryptography- we've got

it on screen here to show you the Alice-and-Bob sort of arrangement between A and B,

you can see there's that key distribution or key management center.

Specifically want to use different terms because in your readings,

you might see different references.

Key Management Center, KMC,

Key Distribution Center, KDC.

There may be even others but those are the two most popular.

We'll go back and forth KDC, KMC.

The idea is at some central authority,

a key authority is providing the keys to the participant,

is literally dropping the keys into their encryption-decryption function.

And you can see Alice provides plain text to the encryption.

It then gets decrypted,

it's now ciphertext over a network where it's received by the decryption function Bob,

decrypts it and then produced as plain text,

and we have our three zones, so to speak.

Client zone, it's plain text, Network zone,

it's ciphertext, Server zone,

it's plain text, right?

Remember, we did some of this in prior videos that securID.

I had you crypto-analyzing stuff.

So, you've already got the basics here but there's

two properties that are awesome with respect to conventional cryptography.

The first is that if Eve is sitting there watching the stuff,

she can't read the cipher text on the network.

Now remember, we said so maybe she goes over to the client,

that's a different problem,

that's a different cyber security issue.

For cryptography, worry about the network and things being encrypted.

And yes, you can use encryption certainly at last on a network but for now,

we're just assuming the cryptography in the network.

Secrecy is one property that we have where Eve can't read the stuff.

The second is that Alice can technically authenticate to Bob.

Bob says, Hey, who are you,

and she encrypts using a shared key and

Bob decrypts it and it makes sense and we'll see what makes

sense is how that's implemented in the context of digital signature in a little bit.

But the idea is that Bob can make sense of that,

he can conclude that it must have come from Alice

or that it may have come from the key distribution or key management center too, right?

So, in a court of law,

be a little careful because if Bob presents evidence to a judge and says,

Hey, look, I got this thing from Alice that says, hey Bob,

you're a big dummy and got me all upset and I'm suing Alice.

The judge would say, well,

it's possible that could have come from Alice,

you're right, or it could have come from the key distribution center or you,

Bob, could have created it.

The legal issues are kind of interesting here.

But for Bob, Bob can confidently state that if

he interrogates Alice and gets something back that's been encrypted properly with key,

K, which is shared between Alice and Bob, then they have authentication.

Those kind of rock.

And what we're going to want to do as we

study conventional cryptography is to make sure that we

don't lose those properties as we mess around

with this and try different types of implementations.

With that, I'm going to leave you.

We'll come back and we're going to do some more kind of

more interesting stuff with conventional encryption. I'll see you on the next video.