I'm going to discuss one other non-solution.
We'll call this one #0B, which is to use a trusted third party.
Here is the idea, that we have some very, very trustworthy place,
and we'll make it green.
People trust things that are green.
We have this very trusty place called TrustyKeys,
and TrustyKeys has a shared secret with each individual in the network.
Now if Alice and Bob want to communicate,
the protocol is Alice sends a message to TrustyKeys
that says she wants to communicate with Bob.
That's step 1 of the protocol.
What TrustyKeys will do is generate some new key,
some new secret key, and we'll call that KAB
because it's for Alice to communicate with Bob.
In step 3, TrustyKeys will send the new key to both Alice and Bob,
and it will send it encrypted using the key that's already shared between those 2 parties.
What it sends to Bob is the encryption using KB, the shared key between
Bob and TrustyKeys of something that says Alice's name
concatenated with the actual key.
And what gets sent to Alice is encrypted with KA,
the shared key between Alice and TrustyKeys and the name Bob
along with KAB.
At this point, both Alice and Bob know KAB
and can communicate securely using KAB to encrypt messages between them.
The quiz, to see if you understand third party key distribution,
what could go wrong with this protocol?
The choices are TrustyKeys can read all the messages that happen between
A and B over their encrypted channel.
TrustyKeys can impersonate any customer that shares the key with TrustyKeys,
and some evil party C could tamper with messages in step 3
to steal the key AB and set up a different key between
Alice and Bob and then steal their traffic.
