WEBVTT 00:00.750 --> 00:08.520 So far we learned how to use BGP to encrypt messages so that only the receiver can read the content 00:08.520 --> 00:09.570 of the message. 00:09.960 --> 00:15.480 To do that, the sender, David, in our example, uses the public key of the receiver. 00:15.480 --> 00:19.020 So the receiver makes their public key public as the name suggests. 00:19.050 --> 00:23.810 That's fine because the public key cannot be used to decrypt messages. 00:23.820 --> 00:26.630 It can only be used to encrypt messages. 00:26.640 --> 00:31.710 So David encrypts the message with the receiver's Johns public key. 00:31.740 --> 00:38.670 The message is sent, and when John receives it, he uses his own private key that he never shares with 00:38.670 --> 00:40.860 anybody to decrypt the message. 00:41.250 --> 00:46.250 Therefore, David can send the message to John in any way he wants. 00:46.260 --> 00:53.100 He can send it as a text message, as an instant message, or even using an insecure service. 00:53.340 --> 00:57.800 That's fine, because if anybody reads the message, they will see gibberish. 00:57.810 --> 01:01.620 They won't be able to see the content unless they have the private key. 01:01.620 --> 01:06.180 And as long as John doesn't share the private key, there is no need for him to share it. 01:06.180 --> 01:10.110 Then nobody will be able to read this message except for John. 01:10.860 --> 01:12.720 So that's really, really good. 01:12.810 --> 01:20.280 The only problem here is that there is no way for John to verify that the message that they received 01:20.280 --> 01:23.100 has actually been sent from David. 01:23.880 --> 01:29.010 So, like I said, for this to work, John needs to make their public key public. 01:29.010 --> 01:32.540 So getting the public key of John is easy. 01:32.550 --> 01:36.270 Therefore John could have it in his signature and his email. 01:36.270 --> 01:38.760 He can have it in his signature in a forum. 01:38.760 --> 01:43.530 He might have it publicly shared because he wants people to send him encrypted messages. 01:43.530 --> 01:47.370 So there is nothing wrong with making your public key public. 01:47.820 --> 01:54.900 The only problem is someone can come in, pretend to be David, use John's public key to encrypt a message 01:54.900 --> 01:56.430 and send it to John. 01:56.490 --> 02:03.300 And that way, John has no way of knowing whether this message did actually come from David or not. 02:04.320 --> 02:08.580 To solve this problem, David will have to sign the message. 02:08.610 --> 02:11.100 This can actually be done with Pjp. 02:11.130 --> 02:14.640 So let me show you how this will work with this example. 02:15.300 --> 02:16.910 So again, we have David. 02:16.920 --> 02:20.160 He wants to send a secret message to John. 02:20.370 --> 02:27.840 And as we learned before, the first thing that David will do, he will use John's public key in order 02:27.840 --> 02:29.180 to encrypt the message. 02:29.190 --> 02:31.650 The message will change into gibberish. 02:31.740 --> 02:38.370 Now, at this stage in the previous lecture, we sent the message, but this time David is going to 02:38.370 --> 02:42.150 sign the message with his own private key. 02:42.300 --> 02:44.340 So he still hasn't sent the private key. 02:44.340 --> 02:46.350 The message is still at David's end. 02:46.350 --> 02:51.140 And what he's going to do is he's going to create a signature for this message. 02:51.150 --> 02:53.880 This signature corresponds to this message. 02:53.880 --> 02:59.820 And if anything gets modified within the message, if one letter gets modified, the signature will 02:59.820 --> 03:00.570 change. 03:00.930 --> 03:07.740 Therefore, this signature can be used to verify that the message has not been modified since it got 03:07.740 --> 03:10.140 signed by David's private key. 03:10.470 --> 03:13.710 Now, keep in mind, David is still keeping his own private key. 03:13.740 --> 03:17.400 He did not send it through any method of communication. 03:18.030 --> 03:24.720 So now we have a message with an encrypted content and with a signature that corresponds to David Private 03:24.720 --> 03:25.260 Key. 03:25.830 --> 03:29.340 Then the message is sent using any method of communication. 03:29.340 --> 03:33.240 Like we said, you can even use an insecure method of communication. 03:33.540 --> 03:41.130 John is going to receive the message along with its signature, and before decrypting this message with 03:41.130 --> 03:49.500 his own private key, what he's going to do is he's going to use David's public key in order to verify 03:49.500 --> 03:50.550 the signature. 03:51.000 --> 03:54.900 So like I said, the signature was created with David's private key. 03:54.900 --> 04:01.200 And then John doesn't have David's private key, but he's going to use David's public key to verify 04:01.200 --> 04:02.100 the signature. 04:02.730 --> 04:07.650 If the message was not modified, the verification will be successful. 04:07.650 --> 04:15.390 And this way John will know that this message was actually sent by David and was not modified by anybody. 04:15.390 --> 04:22.230 Because, like I said, if one letter gets modified, the public key, David's public key will not verify 04:22.230 --> 04:23.130 the signature. 04:24.090 --> 04:29.670 So when the signature is verified, we know that David was the actual sender of the message, and the 04:29.670 --> 04:35.430 message was not modified as it was sent, whether it was sent over the Internet as a text message or 04:35.430 --> 04:37.860 using any other method of communication. 04:37.920 --> 04:41.730 The next step is very similar to what happened in the previous lecture. 04:41.730 --> 04:49.470 John will use his own private key in order to decrypt the message and read its content, which is just 04:49.470 --> 04:50.640 a secret message. 04:51.380 --> 04:57.180 So as you can see, as a result of this, each party still kept their own private key. 04:57.200 --> 05:00.560 Nobody sent their private key to the other party. 05:00.740 --> 05:07.730 So the sender encrypts the message with the receiver's public key and signs the message with his own 05:07.730 --> 05:08.690 private key. 05:08.720 --> 05:10.010 The message is sent. 05:10.040 --> 05:17.270 The receiver verifies the signature with the sender's public key and decrypts it with his own private 05:17.270 --> 05:17.810 key. 05:18.920 --> 05:23.240 This way he can verify that this message came from the sender. 05:23.270 --> 05:27.590 He can verify that the message did not get modified as it was sent. 05:27.590 --> 05:29.510 And the message is encrypted. 05:29.510 --> 05:35.750 And the only person that can read it is the receiver, because he kept his own private key private and 05:35.750 --> 05:37.700 it was not shared with anybody. 05:38.980 --> 05:45.610 Now all of this should become clearer in the next lecture as I'm going to show you how to encrypt messages 05:45.610 --> 05:48.060 and sign them as a sender. 05:48.070 --> 05:55.270 And I'm also going to show you how to verify the signature and decrypt the messages as a receiver.