Okay, so now the nice thing about this design is that now every user only
has to remember one secret key. The question is now, what happens when Alice
wants to talk to Bob? Somehow the two of them have to engage in a certain protocol,
such that at the end of this protocol they will have a shared secret key KAB that the
attacker wouldn't be able to know. And so the question is how do Alice and Bob
generate this shared secret key KAB. So let's look at an example toy protocol for
doing that. So here we have our friends Alice and Bob. As usual Bob has his key
KB, which is shared with a trusted third party. Alice has her secret key KA,
which is also shared with a trusted third party. So here the trusted third party
has both KA and KB. And the question is, how do they generate a shared key that
they both agree on, but the attacker would have no idea what this shared key is? So
here we're only gonna look at a toy protocol. In particular, this protocol is
only gonna to be secure against eavesdropping. It's not gonna be secure
against more tampering or active attacks. As I said, we're gonna come back and
design secure key exchange protocols later on in the course. But for now, just to
introduce this idea of key exchange, let's look at the simplest, simplest mechanism
that's only secure against eavesdropping. So in other words, adversary that listens
to the conversation won't know what the shared key KAB is gonna be. And so the
protocol works as follows. Alice is going to start by sending a message to the
trusted third party saying, hey I want a secret key that's going to be shared with
Bob. What the trusted third party will do is it will actually go ahead and choose a
random secret key, KAB. So the trusted third party is the one who's gonna
generate their shared secret key. And what it will do with this key is the following.
It's gonna send one message back to Alice. But this message consists of, of
two parts. The first part of the message is an encryption using Alice's secret key,
using the key KA, of the message this key is supposed to be used between parties
Alice and Bob, and she includes the secret key KAB inside the message. Okay? So just
to be clear, what's happening here is that the message that gets encrypted is the key
KAB plus the fact that this key is supposed to be a shared key between Alice
and Bob. Okay. And this whole message is encrypted using Alice's secret key. The
other part of the message that the TTP sends to Alice is what's called a ticket.
And this ticket is basically a message that's encrypted for Bob. So in other
words, the ticket is gonna be an encryption under the key KB of, again, the
fact that this key is supposed to be used between Alice and Bob. And she
concatenates to that the, the secret key, KAB. Okay, so again, the message that's
encrypted inside of the ticket is the fact that this key is to be used by Alice and
Bob. And, the secret key, KAB, is included in the ticket as well. Okay, So these two
messages, Here, let me circle them. These two messages are sent from the trusted
third party to Alice. Now I should mention that the encryption system E that is
actually being used here is a CPA secure cipher and we'll see why that's needed in
just a minute. So, this is the end of the conversation between Alice and this
trusted third party. Basically as we said at the end of this conversation,
Alice receives one message that's encrypted for her and another message
called a ticket that's encrypted for Bob. Now at a later time when Alice wants to
communicate securely with Bob what she will do, is of course, she will decrypt
her part of the message. In other words she will decrypt the cipher text that was
encrypted using the key KA and now she has the key KAB. And then to Bob, she's going
to send over this ticket. Bob is going to receive the ticket and he is going to
use his own secret key KB to decrypt it and then he himself will also recover the
secret key KAB. So now they have the shared secret key KAB that they can use
to communicate securely with one another. And the first question to ask is, Why is
this protocol secure? Even if we only consider eavesdropping adversaries. So,
let's think about that for a minute. So, at the moment all we care about is just
security against an eavesdropper, So let's think. What does an eavesdropper see in
this protocol. Well basically he sees these two cipher texts. Right, he sees the
cipher text that's encrypted for Alice. And then he sees the ticket that's
encrypted for Bob. And in fact he might see many instances of these messages, in
particular if Alice and Bob continuously exchange keys in this way he's gonna see
many messages of this type and our goal is to say that he has no information about
the exchanged key KAB. So this follows directly from the CPA security of the
cipher E D because the eavesdropper can't really distinguish between encryptions of
the secret key KAB from encryption of just random junk. That's the definition of CPA
security and as a result, he can't distinguish the key KAB from, you know,
random junk which means that he learns nothing about KAB. This is kind of a very
high level argument for why this is eavesdropping security but it's enough for
our purposes here. So the bottom line is that in this protocol the eavesdropper
would actually have no information about what KAB is. And therefore it's okay to
use KAB as secret key to exchange messages between Alice and Bob. Now let's think
about the TTP for a minute. So first of all, you notice that the TTP is needed for
every single key exchange. So basically Alice and Bob simply cannot do key change
unless the TTP is online and available to help them do that. And the other property
of this protocol is in fact, the TTP knows all the session keys. So if somehow the
TTP is corrupt, or maybe it's broken into, then an attacker can very easily steal all
the secret keys that have been exchanged between every user of this system. This is
why this TTP is called the Trusted Third Party because, essentially, it knows all
the session keys that have been generated in the system. Nevertheless the beauty of
this mechanism is that it only uses symmetric key cryptography, nothing beyond
what we've already seen and as a result it is very fast and efficient. The only issue is
that you have to use this online trusted party and it's not immediately clear if for
example we wanted to use this in the world wide web who would function as this
online trusted third party. However, in a corporate setting this might actually make
sense if you have a single company with a single point of trust it might make sense
to actually designate a machine as a trusted third party. And in fact a
mechanism like this not quite as the way I described it, but a mechanism like this is
the basis of the Kerberos system. So this is our first example of a key
exchange protocol that allowed Alice and Bob to set up shared keys, however I
really want to point out that this is just a toy protocol. Very, very simple and is
only secure against eavesdropping attack. It's actually completely insecure
against an active attacker. And here's a very simple example of how an active
attacker might destroy this protocol, and so let's just look at replay attacks. So
here imagine the attacker records the conversation between Alice and some online
merchant. Let's call him Merchant Bob. So for example, imagine Alice orders a book
from the merchant Bob and the transaction completes and Bob accepts payment for this
book. And actually sends Alice a copy of this book. What an attacker can do now
is, he can complete, completely record the conversation and simply replay the
conversation to merchant Bob at a later time. Bob will think that Alice just
reordered another, another copy of the book and he'll charge her again for it,
and send her this, this copy again. So essentially by replaying a conversation
you can cause quite a bit of harm to Alice, and as a result this is a simple
example of why this protocol is completely insecure against active attacks, and
should never be used in the real world. As I said we're going to come back in a few weeks
and talk about secure versions of this protocol, and you'll see how to make this
work, in the real world. Nevertheless, you see that this, this very simple protocol
already raises a very interesting question. And the question is, can we
basically design key exchange protocols whether they're secure against
eavesdropping or secure against active attackers. The question is, can we design
key exchange protocols that are secure, but work without an online trusted third
party. So we don't wanna rely on any online trusted party that's necessary to
complete the key exchange protocol. And so the amazing answer is that in fact this is
possible. We can do key exchange without a trusted third party. And this is, in fact,
the starting point of public cryptography. So I'm gonna show you three ideas for
making this happen and we're gonna talk about them in much more detail in the, in
the coming modules. So the first idea is actually due to Ralph Merkle back in 1974.
This was, he was, when he was just an undergraduate student. And already he came
up with this really nice idea for key exchange without an online trusted third
party. So that's one example that we're gonna look at. Another example is
due to Diffie and Hellman. Back in 1976 they both actually, working here at
Stanford University, came up with this idea that launched the world of modern key
cryptography. And the third idea is due to Rivest, Shamir and Adleman working at MIT and
we're going to look in detail exactly how each of these ideas work. But I do want to
mention that the work on public key management hasn't stopped in the late
seventies. In fact there have been many ideas over the years and here I'll just
mention two from the last decade. One is call identity based encryption, which is
another way for managing public keys. And another is called functional encryption,
which is a way of giving secret keys that only partially decrypt a given cipher text.
And so we're gonna talk about the core of public key crypto in this and the next week
and we'll talk about these more advanced ideas later on in the course.
