WEBVTT 00:00.140 --> 00:00.650 Huron. 00:00.650 --> 00:01.610 And welcome back. 00:01.610 --> 00:06.230 In today's video, we will be discussing about the asymmetric key encryption. 00:07.010 --> 00:14.180 Now, the asymmetric key cryptography makes use of public and private keys to encrypt and decrypt the 00:14.180 --> 00:14.670 data. 00:14.690 --> 00:17.840 So let's understand this in a simple way. 00:17.870 --> 00:24.620 So what happens in asymmetric key encryption is that there are two keys which are involved, and these 00:24.620 --> 00:27.800 two keys are in some way related with each other. 00:28.130 --> 00:36.170 So what happens here is that whatever data that you encrypt with one key can only and only be decrypted 00:36.170 --> 00:37.450 with the second key here. 00:37.550 --> 00:44.990 And in a similar way, whatever data that you encrypt with, the second key can only be decrypted with 00:44.990 --> 00:45.740 the first key. 00:45.920 --> 00:48.830 So that's the basic concept of asymmetric key. 00:49.130 --> 00:56.400 So here it is referred the two keys are referred as public key and private key. 00:56.420 --> 01:00.720 So one key is public and second key is private. 01:00.750 --> 01:07.830 Now, as the name suggests, the public key can be shared with everyone, so you can share it across 01:07.830 --> 01:08.460 the Internet. 01:08.460 --> 01:09.600 There is no issue there. 01:09.600 --> 01:15.210 And the other key is kept as secret and you do not share it with anyone. 01:15.210 --> 01:18.180 And it is called as the private key. 01:18.210 --> 01:24.990 So as we discussed, either of the keys can be used to encrypt a message and the opposite key from the 01:24.990 --> 01:29.350 one which is used to encrypt the message is used for decryption. 01:29.370 --> 01:30.960 So let's understand this. 01:30.960 --> 01:33.360 Let's say that you have a user. 01:33.390 --> 01:34.840 Her name is Alice. 01:34.860 --> 01:37.170 So Alice generates two key. 01:37.200 --> 01:40.770 One is the public key and second is the private key. 01:40.890 --> 01:47.490 So now once the keys are generated, she can go ahead and distribute the public key among the Internet. 01:47.490 --> 01:53.430 And she can say that anyone who wants to send me a message, encrypt that message with my public key 01:53.430 --> 01:55.020 and send that across. 01:55.050 --> 02:01.650 So once that message is encrypted with the public key, we know that it can only be decrypted with the 02:01.650 --> 02:04.710 private key which the Alice user has. 02:05.010 --> 02:09.930 So what Bob does, Bob has a message called as Hello Alice. 02:09.960 --> 02:17.550 He encrypts that message with the Alice's public key and you have the resultant encrypted message. 02:17.940 --> 02:24.780 So now this resultant encrypted message is something that he can send across the Internet or across 02:24.810 --> 02:26.670 a unsafe network. 02:26.940 --> 02:29.460 So now what Alice will do? 02:29.490 --> 02:32.110 Alice will get this encrypted message. 02:32.130 --> 02:37.650 She will decrypt that message with the Alice's private key and read it. 02:37.800 --> 02:39.750 So here she can read. 02:39.780 --> 02:40.680 Hello, Alice. 02:40.800 --> 02:44.430 So this is the role of public and private key. 02:44.880 --> 02:49.860 So this can also be better explained with one more diagram where you have the sender. 02:49.860 --> 02:55.500 Sender makes use of the public key to encrypt this plaintext document. 02:55.500 --> 03:02.790 So this plaintext document and the public key encrypts the document and with the corresponding private 03:02.820 --> 03:05.490 key, it's not like you cannot use any other private key. 03:05.520 --> 03:11.100 You only have to use the private key, which is associated with this specific public key through which 03:11.130 --> 03:12.310 it is encrypted. 03:12.330 --> 03:18.810 So through the private key, you can go ahead and decrypt the message and receiver will have the proper 03:18.810 --> 03:19.650 message here. 03:20.010 --> 03:20.460 All right. 03:20.490 --> 03:27.540 Now, in fact, let me quickly show you, because asymmetric key is used in a lot of applications. 03:27.540 --> 03:34.260 So generally at Cape Labs, what I do is whatever sensitive data that I send across the Internet, which 03:34.290 --> 03:39.070 includes email, all of that data is in the encrypted state. 03:39.090 --> 03:46.450 So you can see that I have sent an email credentials to one of the person who recently joined Cape Labs. 03:46.470 --> 03:52.480 So all of the messages, if you look into the message, this is completely encrypted mail. 03:52.500 --> 04:01.800 So even if a attacker is able to read this mail, he will not be able to decrypt it because this message 04:01.800 --> 04:03.810 is encrypted completely. 04:03.840 --> 04:09.130 So how things work, let's say that I have to send a message to Alice. 04:09.150 --> 04:12.840 So what I do, I tell Alice to send me her public key. 04:12.870 --> 04:19.140 Once she sends me her public key, I encrypt the message with her public key. 04:19.290 --> 04:22.560 And this is how the encrypted message looks like. 04:22.560 --> 04:23.670 It is quite big. 04:23.670 --> 04:27.810 And then I send it across towards her email. 04:27.840 --> 04:34.690 Now she can make use of the private key and decrypt the credentials accordingly. 04:34.710 --> 04:41.280 Now in between, if there is a attacker who is reading a mail or even let's say that there is a Google 04:41.280 --> 04:45.840 employee who is reading the mail, he will not be able to find out because this is encrypted. 04:45.840 --> 04:53.640 So even if there is someone who has access towards the email and he is able to read everything, still 04:53.640 --> 04:55.800 he will only see this encrypted block. 04:55.800 --> 04:59.120 He will not see the email credentials. 04:59.130 --> 04:59.850 So let's. 04:59.870 --> 05:00.620 Understand. 05:00.670 --> 05:03.230 A second use case of asymmetric encryption. 05:03.230 --> 05:09.210 So this is a typical use case when a user wants to log in to a Linux server. 05:09.260 --> 05:13.350 So what happens here that you have a user, you have a server? 05:13.370 --> 05:17.840 Now, the server basically contains the user's public key. 05:17.870 --> 05:18.440 All right. 05:18.440 --> 05:21.980 So for here you see, zeal has its own public key. 05:21.990 --> 05:27.600 So all the public key of the user who might want to log in to the server is stored in the server. 05:27.620 --> 05:29.400 So let's understand this step. 05:29.420 --> 05:32.360 So user zeal wants to log in to the server. 05:32.390 --> 05:39.260 Now, since the server uses public key authentication, so instead of taking the password from the user 05:39.260 --> 05:45.680 server will verify if the user claiming to be zeal actually holds the private key. 05:45.710 --> 05:49.670 So here the first request via SSH is I am zeal. 05:49.670 --> 05:50.900 I want to log in. 05:51.110 --> 05:53.180 So server receives that message. 05:53.180 --> 05:55.850 Server says prove by solving this. 05:55.880 --> 05:58.670 All right, so this is encrypted over here if you see. 05:58.670 --> 06:00.550 So this becomes the step two. 06:00.570 --> 06:04.770 So what happens in step two, The server creates a simple challenge. 06:04.770 --> 06:07.830 Let's say two plus three is equal to question mark. 06:07.980 --> 06:16.320 And this simple challenge, it will encrypt it with the public key of the user and send it back to the 06:16.320 --> 06:16.860 user. 06:16.890 --> 06:17.430 All right. 06:17.460 --> 06:25.140 Now, this is in a encrypted format and it is encrypted by the public key associated with the zeal user. 06:25.140 --> 06:33.150 So only the person who holds the Associated private key will be able to decrypt the message. 06:33.150 --> 06:40.290 So if it is public key, then it is assumed that zeal will hold its private key. 06:40.320 --> 06:47.970 Now, within the step three, since user zeal holds the associated private key, he will be able to 06:48.000 --> 06:53.830 decrypt the message and the answer is computed, which would be five. 06:53.850 --> 06:57.600 So here the challenge is two plus three is equal to question mark. 06:57.600 --> 07:02.520 And this challenge was encrypted with the zeal public key and send it across. 07:02.550 --> 07:03.270 Now zeal. 07:03.270 --> 07:10.350 Since he holds the private key, he quickly decrypts the message and he computes the answer as five. 07:10.380 --> 07:18.420 He encrypts that message, which is the answer as five with the private key and sends it back to the 07:18.420 --> 07:19.080 server. 07:19.110 --> 07:19.410 All right. 07:19.410 --> 07:26.910 So in stage three, the answer is encrypted with the private key and it is sent back to the server. 07:27.390 --> 07:34.920 Now, in the step four, the server basically decrypts the message with the public key and check if 07:34.920 --> 07:36.090 the answer is correct. 07:36.120 --> 07:45.210 Now, do remember that if the user or in our case, if zeal has encrypted the message with the private 07:45.240 --> 07:52.380 key, it can only be decrypted with the corresponding public key and it cannot be decrypted with any 07:52.410 --> 07:53.790 other public key. 07:53.820 --> 07:54.600 All right. 07:54.600 --> 07:57.380 So server receives the answer. 07:57.390 --> 08:00.360 It decrypts the answer with the zeal. 08:00.450 --> 08:01.290 Public key. 08:01.320 --> 08:08.130 So since the message is decrypted, the server can know that it was encrypted with the corresponding 08:08.130 --> 08:10.480 private key which user zeal hold. 08:10.500 --> 08:18.540 And this is one of the ways in which it knows that an individual who wanted to log in has the correct 08:18.540 --> 08:25.050 associated private key, and it also looks into the challenge and then sends the authentication successful 08:25.050 --> 08:25.560 message. 08:25.560 --> 08:30.750 So this is one of the approaches for asymmetric key encryption. 08:30.750 --> 08:32.830 So let me quickly show you this. 08:32.850 --> 08:41.460 So here, whenever I am logging in through SSH, you will see with the hyphen I am specifying the private 08:41.490 --> 08:42.180 key here. 08:42.210 --> 08:42.930 All right. 08:42.930 --> 08:49.200 So when I press enter here, this is just an additional password to the private key. 08:49.500 --> 08:52.230 It automatically logged me in. 08:52.260 --> 09:01.150 Now, if you basically look into the authorized keys here, it basically contains the public key. 09:01.170 --> 09:05.780 So if you look into the diagram, the server hold the public key here. 09:05.820 --> 09:06.450 All right. 09:06.450 --> 09:11.820 So this public key was used to compute the appropriate challenge. 09:11.850 --> 09:17.800 Depending upon the protocol that you are using, you can quickly generate a public private key pair. 09:17.820 --> 09:20.250 So if you just do a ssh key gen. 09:21.510 --> 09:22.170 All right. 09:22.170 --> 09:27.140 So now it automatically generated a public key and the private key. 09:27.150 --> 09:33.120 So if you see your public key has been saved here and your identification, which is your private key, 09:33.150 --> 09:33.960 has been saved. 09:34.110 --> 09:39.520 So if you go to the SSH directory, you will see that one is public key. 09:39.540 --> 09:42.400 So this is public key and second is private key. 09:42.420 --> 09:49.380 So if you just want to see how public key looks like this is how the public key looks like, and if 09:49.380 --> 09:55.050 you want to see how private key looks like, this is how the private key looks like. 09:55.050 --> 09:58.130 So this is a big key, which is difficult to remember. 09:58.140 --> 09:59.790 So this is. 09:59.810 --> 10:04.610 One of the ways of asymmetric key encryption, and this is the recommended approach. 10:04.610 --> 10:10.160 So generally whenever you go in organizations and enterprises and if you want to log in to the server, 10:10.190 --> 10:16.040 they'll generally ask you, okay, generate a public private key pair and send us the public key and 10:16.040 --> 10:21.890 the system administrator will go ahead and put your public key within the server and through the private 10:21.890 --> 10:23.720 key you will be able to log in. 10:23.720 --> 10:31.610 And this is similar where I had sent an email with encrypted with the public key of the user and this 10:31.610 --> 10:36.980 mail is being received by the user, so he'll be able to decrypt it with the corresponding private key. 10:37.130 --> 10:44.770 Now, because of the advantages that it offers, asymmetric key encryption is used by a variety of protocols. 10:44.780 --> 10:51.470 So some of these protocols are BGP, you have, you have Bitcoin, you even have TLS. 10:51.470 --> 10:58.850 So the SSL websites that you might see with Green Bar TLS also extensively makes use of the asymmetric 10:58.850 --> 10:59.700 encryption. 10:59.700 --> 11:02.340 You also have Smime, which uses this. 11:02.340 --> 11:07.320 So these are some of the protocols which extensively uses asymmetric key encryption. 11:07.320 --> 11:09.420 Again, this is just a small list. 11:09.420 --> 11:11.220 There are a lot of others as well. 11:11.340 --> 11:13.170 So that's the high level overview. 11:13.170 --> 11:19.920 I hope you understood asymmetric key encryption at a glance, and I hope this video has been informative 11:19.920 --> 11:22.350 for you and I look forward to see you in the next video.