Todo this'd very strange.

Welcome.

Remote.

All right, well, Steve did a great video on BP ends and how to have work remotely.

Right now, we're all doing this.

So I thought I'd talk also a little bit about networking or, you know, a cryptographic protocol, um, that we often use over networks.

In one of my previous videos, I talked about quantum computing and what kind of effect, if any, that would have on encryption.

And the answer, really is that it has quite a big effect on public key cryptography, but not that big an effect on on symmetric of geography.

You know, that's assuming we can build bigger quantum computers sometime.

Now, what I wanted to talk about today is a really cool protocol, but actually sees a lot of use particularly, I mean, everywhere, right on lots of different operating systems, but particularly on active directory is its main authentication mechanism.

And that's curb Ross, right?

Remember, curb off the three headed dog that guards ain't Haiti's, is it?

So it has a cool name.

We're off to a good start.

Curb loss is a really interesting protocol because away, off managing authentication and communication over a network like a giant enterprise level network.

But it does it without really requiring any kind of public key.

It'll eso it does it all with symmetric encryption.

So it is inherently very robust to any kind of quantum computer.

So Kirby was invented in the seventies.

M I t on.

It's still maintained by a mighty, but obviously, in recent years, no barriers have appeared in things like Windows Active Directory.

I'm just gonna talk in general about her boss.

I'll try and draw attention to the differences between you know, the actor director of Asian.

But mostly it's naming differences, really, is what we're concerned with.

One of the issues, if we're going to use only symmetric encryption, is we have to work out how to share keys.

We can't do key exchange because that's public key.

We can't verify people using something like certificates, because that's our say, that's public key.

So what do we do?

Well, one of the ways we can share Keith is using passwords so we could derive a key.

I could take my password.

I could hash it in some known way, and then we could you could do the same thing.

If you were server but new my password or knew the hash on dhe, we could have a shared secret that way.

So okay, let's say we want to do this right.

Well, now let's think about the number of machines on a standard corporate network like maybe there's 2000 laptops on any given day kick to the network and 10,000 desktops on DDE 200 servers.

How many of these passwords are we using?

A veil shared.

You were different passwords, different keys.

Let's use a very simple example.

Let's imagine we have a network with 10 machines, so I'm just gonna draw 10 machines.

Should do one fewer machine's list.

You know what?

I can undo this.

I can say five machines now if I wanna have a shared key.

But it's, let's say different for security reasons.

Between all of these machines, it's gonna look something like, I think that's all of them, right?

I mean, if I had another machine, a sick machine here, I've got to do this on 1/7 machine.

This is an absolute mess, but because we can't do key exchange so normally what you would do on the Internet is you would just talk to a machine to a quickie exchange, and then you've got yourself a session key for the rest of that conversation.

We can't do that because that's a public key protocol which is vulnerable to things like Quantum.

And also actually, at the time, I don't think if hell existed when this was first developed.

Right?

At least the protocols underpinning this so we're not gonna use public key is a solution.

We're gonna come up with something different.

What we're going to try and do is use the fact that we have this server, which I'm gonna draw Sort of nice and big here.

Server A big s on it, like the Superman, this server we all trust on because we will trust that server.

We can use that to give us temporary keys.

So in orange, I'm gonna draw.

Let's imagine that these machines now have long term keys with this server.

Right?

So there's now 123457 keys There, seven permanent keys, Probably based off passwords.

It would be a server.

We will trust the server for now.

So that's good.

Now let's imagine that this machine wants to talk to this machine.

What we do is we ask the server to send us a key that we can use for that conversation, and it just generates one at random on protects it using these encrypted channels on, then weaken temporarily use this green key for our session.

So the key exchange is now using this trusted third party.

So this is kind of what curb bosses about.

It has the benefit, but it doesn't rely on public key, but also there's an inherently, really elegant.

Waving it off indicates you because basically, you can't talk between these two machines and let's face it, giving you a key to do it, which is in some sense giving you permission to do it.

If it's too far, serve when you want access to far server.

It's only gonna work if you've got a key from here on dhe.

If it doesn't give you one because you're not allowed, good luck getting into the file server, right?

That's the idea.

So it's quite a neat trick, but gets around just using symmetric and has this authentication built in that Kurt Boss is also a little bit more complicated than this.

So that's what we're gonna delve into now.

We're going to be on a fictitious network now, and this is me over here now.

You know, as you know, from my previous videos, I'm very good at drawing computers, and they always look realistic.

So this is by little desktop.

So this is me.

I'm gonna be a A for Alice saw, you know?

And here we have our authentication, our ticket granting service.

NOBITA part off Curb.

Boss, we're gonna have a big machine over here, and this is gonna have to servers in it or to Service is now in the original kerb lost.

This would be called a key distribution center or K.

D.

C.

Often this role is performed by something called a domain controller on active directory.

Now, in here we have two kinds of servers.

We have our authentication server, which I'm going to call s and our ticket granting server, which I'm going to call t on dhe.

Everything to do with authentication and connecting to, like an active directory or any other kind off herb or set up is going to be using these to service is so the authentication server is going to be responsible for checking your password essentially and making sure you actually do have an account on that directory or that network And the ticket granting service is going to be responsible for issuing tickets, which you can use to go on access things like file servers or printers or whatever else it is on the network.

The first thing to do is to approach the authentication server a shooting.

We've already had an account created and send him a message.

So we're gonna send him a message which says my name is a I would like to talk to the ticket granting server on here is a random number that I'm going to use to prevent replay attacks.

We're not gonna worry too much about them, which could've passing back and forth.

But the point is, I'm sending a message not really necessarily encrypted to this authentication server that I'm A and I'd like to talk to a ticket wanting server.

Now, the importing here is assuming that a has an account it has established key between A and S.

I have a key A s, which I can use to talk to about server for the long term because it's based on my past would maybe I only take them apart with every 12 months or whatever.

My past is very good.

I don't have to change it.

I should I should.

I should notice now.

So I'm gonna send this message across T s now s is going to reply.

S is going to send a message which is encrypted, assuming it allows me to talk to T.

It's going to send me some messages that mean I can bend talk to t.

Right, So the 1st 1 is going to be.

Here's a key k A.

T that you can use to talk between these two.

Here's your nonce back again to prevent replay attacks.

This is the current time.

This is the lifetime of his ticket on dhe.

You're OK to talk to the ticket granting server, so it just has a lot of different parts to this message.

The things to bear in mind are so the time stamp on the lifetime of Soviet you can't like, hold onto a ticket for salt two years and play again on dhe.

You know, we have the names of things in there to make sure of when those who is supposed to be talking to.

So the important thing in this message is this key K A T.

What?

I'm using 80 to symbolize this.

A session key between A and T.

Now, I don't have a long term key with T.

My computer doesn't have that.

This is generated on the fly by this server.

Now, this is encrypted dismissive because we can't re sending keys over the Internet, not encrypted.

So this is gonna be encrypted with my very well drawn curly brackets.

And this is gonna be encrypted using K A s, which is, of course, our long term key between A on the authentication server.

What I can do now is I can decrypt this message using K s because that drives off my password.

I can read this session key and then I can use it to talk to T.

The problem is that he doesn't have this session key like this is news that bland new this key so it's going to send S is going to send me some or information.

It's gonna send me the same k 80.

It's going to say this is to talk to a Andi.

This is the lifetime of that ticket, and this is going to be encrypted with K S t.

So this the authentication server s is going to use a long term key S t to encrypt this message, which I can't need, right, Because I don't have s t I'm a So this is a ticket that I can pass to tea for it to use, and only it can understand.

So this is called a wonderfully named ticket granting ticket.

It's a ticket that's gonna let me get more tickets in the future.

So I take this first message decrypted, and I have the session.

Kate, I need I forward this message on to the ticket granting server It decrypt sit, and assuming it's okay, it now has the message that it needs.

That's kind of cool.

Um, this is all that.

The other really nice thing about this is, but it's fire and forget.

So this authentication server come very quickly.

Look me up in database fire back these two new session keys encrypted, and then it's done.

Its work is done.

It's authenticated me.

That's the end of the discussion it doesn't need to talk to me anymore until I love on another time.

So the next thing I have to do I want to talk to some kindof server file server.

Let's say Colby, now, we can't do that yet because we haven't got a ticket, and in that ticket is gonna be a new session key that we can use to encrypt that conversation.

So I'm going to send a message.

I'm gonna use my purple again.

Kind of kind of messed up.

The colors will do our best.

So I'm gonna send a message now to tea, and that's gonna be first of all this ticket.

That ticket says I'm a and this is my new session key that we can use on this has kind of been stamped as it were.

It's been authenticated by the fact that it's encrypted by K.

S.

T.

Which is the authentication service Private key with this tea here.

So I'm gonna send my name is a This is a time stamp to make sure everything is taking place at the right time.

I'd like to talk to be please on dhe.

This is some new random number that we're going to use to prevent me play attacks on this is all gonna be encrypted using the K A T session key we've just obtained.

Okay, 80.

So only me and t can read that.

I have to take this and I also forward on the ticket.

It decrypt the ticket, and now it has access to Katie and can read my message.

No one else can.

This is what her boss is a clever And so this ticket guarding server is gonna look at me and it's gonna look at my account, and it's gonna look at what B is on work out.

Whether it is OK that I actually talked to be right now, assuming that's the case, it's gonna respond.

It's gonna send me back.

Let's go green for this one wide.

It's gonna do exactly the same as the authentication service is.

So it's gonna produce me a new random key to be used to talk to bay, which we're gonna call K A B.

So we're not forget super confused.

It's okay, a B on.

We're gonna reply with the random number as well to prevent replay attacks.

This is the time stamp off the server.

This is a lifetime of this ticket on dhe.

Finally, I would like you to talk to Bay on Dhe.

Of course, this is gonna be encrypted using our key between A and T like a 80.

Since everyone's in, messages are encrypted with their own session key or their own long term key, depending on which one you're talking to.

And, of course, what else does it need to send?

Well, we need be to be able to have this k a B in order to have a conversation, so it's gonna have to send another ticket toe.

Let us access be.

So this is gonna have kay.

Maybe it's a vassal.

Shared secret.