So far we learned how to use BGP to encrypt messages so that only the receiver can read the content
of the message.
To do that, the sender, David, in our example, uses the public key of the receiver.
So the receiver makes their public key public as the name suggests.
That's fine because the public key cannot be used to decrypt messages.
It can only be used to encrypt messages.
So David encrypts the message with the receiver's Johns public key.
The message is sent, and when John receives it, he uses his own private key that he never shares with
anybody to decrypt the message.
Therefore, David can send the message to John in any way he wants.
He can send it as a text message, as an instant message, or even using an insecure service.
That's fine, because if anybody reads the message, they will see gibberish.
They won't be able to see the content unless they have the private key.
And as long as John doesn't share the private key, there is no need for him to share it.
Then nobody will be able to read this message except for John.
So that's really, really good.
The only problem here is that there is no way for John to verify that the message that they received
has actually been sent from David.
So, like I said, for this to work, John needs to make their public key public.
So getting the public key of John is easy.
Therefore John could have it in his signature and his email.
He can have it in his signature in a forum.
He might have it publicly shared because he wants people to send him encrypted messages.
So there is nothing wrong with making your public key public.
The only problem is someone can come in, pretend to be David, use John's public key to encrypt a message
and send it to John.
And that way, John has no way of knowing whether this message did actually come from David or not.
To solve this problem, David will have to sign the message.
This can actually be done with Pjp.
So let me show you how this will work with this example.
So again, we have David.
He wants to send a secret message to John.
And as we learned before, the first thing that David will do, he will use John's public key in order
to encrypt the message.
The message will change into gibberish.
Now, at this stage in the previous lecture, we sent the message, but this time David is going to
sign the message with his own private key.
So he still hasn't sent the private key.
The message is still at David's end.
And what he's going to do is he's going to create a signature for this message.
This signature corresponds to this message.
And if anything gets modified within the message, if one letter gets modified, the signature will
change.
Therefore, this signature can be used to verify that the message has not been modified since it got
signed by David's private key.
Now, keep in mind, David is still keeping his own private key.
He did not send it through any method of communication.
So now we have a message with an encrypted content and with a signature that corresponds to David Private
Key.
Then the message is sent using any method of communication.
Like we said, you can even use an insecure method of communication.
John is going to receive the message along with its signature, and before decrypting this message with
his own private key, what he's going to do is he's going to use David's public key in order to verify
the signature.
So like I said, the signature was created with David's private key.
And then John doesn't have David's private key, but he's going to use David's public key to verify
the signature.
If the message was not modified, the verification will be successful.
And this way John will know that this message was actually sent by David and was not modified by anybody.
Because, like I said, if one letter gets modified, the public key, David's public key will not verify
the signature.
So when the signature is verified, we know that David was the actual sender of the message, and the
message was not modified as it was sent, whether it was sent over the Internet as a text message or
using any other method of communication.
The next step is very similar to what happened in the previous lecture.
John will use his own private key in order to decrypt the message and read its content, which is just
a secret message.
So as you can see, as a result of this, each party still kept their own private key.
Nobody sent their private key to the other party.
So the sender encrypts the message with the receiver's public key and signs the message with his own
private key.
The message is sent.
The receiver verifies the signature with the sender's public key and decrypts it with his own private
key.
This way he can verify that this message came from the sender.
He can verify that the message did not get modified as it was sent.
And the message is encrypted.
And the only person that can read it is the receiver, because he kept his own private key private and
it was not shared with anybody.
Now all of this should become clearer in the next lecture as I'm going to show you how to encrypt messages
and sign them as a sender.
And I'm also going to show you how to verify the signature and decrypt the messages as a receiver.