Finally a tutorial that explains the relationship between the public and private key. Thanks. So many videos take for granted that the public key is sent but in the end the private key magically decrypts 'somehow'. This makes it so much easier to understand.
I’m glad the analogy was helpful, K-San. I wish I could take credit for it but heard it somewhere else (can’t remember where) and found it very helpful as well. All the best.
After days of searching on this topic this is, by a country mile, the best explanation of encryption I have come across. Paul, as someone who has run many training courses myself, you articulate difficult concepts exceptionally well. Andy.
Spending time this morning tuning up on cryptography concepts, and loving that I can get the refresher from the guy who taught me everything I know about this. You are so good at this stuff. Miss our interactions. Hope you are well, my friend.
This is literally is the last piece of the jigsaw I was looking for and where it all comes together in understanding pki and certificates.Videos of such crystal clear explanatory quality about intricate technical stuff are few and far between.You took it to a whole different level, especially the last part where I experienced an epiphany when you combined the challenge of confidentiality with sender authentication.Thanks a lot Paul and keep up the good work!
Thanks for the kind feedback, Bernard. I’ll have to tell my kids that someone thinks I have a comforting voice. They’ll likely be surprised 😲 Seriously, I do appreciate it!
Nice Lecture. I just wanted to add that Certificate contains Digital signature which is just an Encrypted Hash that can be decrypted using the public key(verifying the sender), and the integrity can be verified with the Hash. For more information on who signs it, who checks it, watch further the video series on PKI, very well explained here. Thanks, Paul.
Despite numerous encryption videos no RUclips, I believe this is the clearest and succinct one to explain these concepts in such as short period of time...bravo~
Excellent Video and great Effort Paul. As one of the comment already pointed out, I don't know even a paid training would be able to teach in such detailed manner. I appreciate your effort. Keep it up.
Very clear and helpful. It's difficult to get a good grasp of these concepts if you're going into IT type of stuff but haven't studied something of that sort.
Wow - am not a security guy - and I feel like an expert now ;) So lucid and easy to understand - was struggling to understand these key management concepts earlier - Great Video Paul - keep up the great work.Thanks a ton!!
Thanks for taking the time to leave a comment, Ezra. Years ago, a great mentor taught me that pictures are an important tool to facilitate understanding. Since then, I’ve enjoyed experimenting with PowerPoint to communicate concepts. I really do appreciate your feedback and wish you the best!
i love your wonderful and very patient approach you took to explain it, it is hard to simplify it because simplification and analogies can induce deeper questions on the actual logic of how the whole thing really fits together and how it actually operates, but you made a serious conceited effort nonetheless. Was anyone else here left with the question of "Why" the man in the middle is NOT able to resurface on the picture after the introduction of certificates ? I mean, the man in the middle simply has to wrap his public key with a {fake} certificate and he can certainly continue to perpetuate his illicit acts of mediating between the two parties ?? LOL, i know the answer but I just wonder if ANYONE else here had that question lurking in the back of their minds when suddenly the solution to eliminate the middleman was simply the introduction of a certificate whereby the public key is simply "wrapped" inside a certificate and "walla" . . the middleman is defeated just like that ?? did it strike ANYBODY else here as "No way, the middleman WILL certainly persist becuz he will simply fabricate a certificate and wrap his malicious public key inside that fabricated certificate so he will therefore PERSIST with or without the introduction of certificates" ?? Hahahahaha, LOL
Tebogo, thank you for making me laugh. You’re right that I simplified things for the sake of making the basic concepts (hopefully) easier to understand. It is possible for a MitM to mint a forged certificate but they have to do it from a CA that the relying party trusts. With the emergence of Let’s Encrypt, this has become easier, but the MitM still has to then compromise DNS or the legitimate server they’re trying to MitM to successfully get a rogue cert. You bring up a good point about certs versus raw public keys, and the potential disadvantages of each. The explicit trust afforded by raw public keys (and self-signed certs, for that matter), makes MitM more difficult as long as you can reliably manage all of the trust relationships. SSH is a good example of this (where the weaknesses include users blindly accepting server public keys or authorized keys being left around forever). Certs can reduce the management headache but then thrust the trust into a smaller number of entities (CAs) that must be secured. I loved the humor and the accompanying thought provoking points. Thanks a bunch.
I'm glad it was helpful. It took me a while to understand these topics. I was hoping to be able to explain it so that others wouldn't have to take so long. I really appreciate your feedback.
Hey, Rocky. Thanks for the kind feedback. In response to your question, the beauty of asymmetric cryptography is that private keys do not need to be shared (should not be shared). If Party A wants to send something confidential to Party B, they get a copy of Party B’s cert (public key), encrypt the information with that, and send the encrypted info. Party B decrypts it with their private key (no private key sharing needed). Alternatively, if Party A wants to authenticate a message that they’re sending to Party B, they encrypt it with their own (Party A’s) private key and send that message to Party B. Party B then confirms it came from Party A by decrypting it with Party A’s cert (public key). Again, no need to exchange private keys. Public keys are shared but private (secret) keys are not. Secret keys are typically only exchanged in symmetric crypto. I hope this makes sense. (I kept it simple up top but, to be clear, when authenticating, Party A encrypts a hash of the message with their private key.)
The presentation doesn't state clearly that the subject's public key is the primary piece of information that the certificate provides and that all the other fields are provided to ensure the validity of this key: with a certificate, the public key is part of that certificate. Alice can now use this public key to decrypt the certificate signature, validate it and encrypt her own message to be sent to Bob.
Hi, Petroleum. Thanks for the feedback. The video was getting pretty long so I put more information about certificates in other videos, which are in my channel. However, it appears you already have a good grasp of the concepts.
very clear and clean video; just one question, at 15:12, how can the receiver decrypt the message with the received public key? from my understanding, public key is for encrypting only (not decrypting), while private key is for decrypting (and for encrypting too, if needed), am I wrong?
ok, maybe I got it; the encryption/decryption function via public/private key can be used this way: {plainmessage}---publickey--->{cryptedmessage}---privatekey--->{plainmessage} as well as this other way: {plainmessage}---privatekey--->{cryptedmessage}---publickey--->{plainmessage} hence the authentication is a kind of reverse form of (indeed you stated "turn the asymmetric cryptography around" at 14:08) of asymmetric encryption for communication.
Thanks a bunch for the great question, and your follow up, which looks correct. My explanation in the video didn’t distinguish between public key algorithms but implies RSA. The RSA algorithm which provides the ability to encrypt/decrypt in both directions (for signing or confidentiality). DSA and ECDSA only allow for encryption with the private key and decryption with the public key (for signing). Diffie Hellman (DH) works yet another way, where both parties create key pairs and exchange their public keys to generate a symmetric session key (for confidentiality). I hope this doesn’t further confuse things for you but I thought I would provide a little more background.
Thanks for posting the comment, I had the same question. Some part of it is clear now from the reply of Paul. But still I doubt after 16:35 if both parties have public keys already exchanged then why some one will use his private key to encrypt and use an algorithm (like RSA) which can encrypt and decrypt using public key, instead both parties can stick to an algorithm where only private key can decrypt, in that case they can use their partner's public key to encrypt and and send data, and their partner will decrypt using their own private key. Sure I'm missing something.
Hi, Flavio. Good question. The client the application software for the user on the left) will only trust certificates that have been issued by certificate authorities (CAs) that it trusts. The man in the middle would need to get access the private key of one CAs that the client trusts in order to forge a certificate. My other videos on PKI help answer this question visually (instead of me attempting to answer in text). Can you please look at those and see if they answer your question? If not, send me another comment and I will attempt to explain in a response.
I was wondering about the significance of certificates, you nailed it. Great video and I enjoyed watching it. Wondering what if the man in the middle spoofs the certificate that its been issued by the legit party. which body issues the certificate?
Hi, Vishnu. I may need you to clarify your question but I’ll try to provide an answer. An MITM can only succeed if the relying party (typically the party who initiated the connection) trusts the issuer of the certificate that the MITM presents. This means that the MITM can’t use a self-signed cert. Instead, they have to convince a CA trusted by the relying party to issue them a certificate with the identity of the subject of the cert (the party that the relying party is communicating with). This should be very difficult if the CA does sufficient due diligence. There have been cases where an MITM compromised the DNS account of the subject and was then able to get Let’s Encrypt to issue them a cert (since LE will issue a cert based on a DNS verification). I hope this helps. Please tell me if it doesn’t answer your question.
good video overall. everything was making total sense up until that very last scenario. that was kind of confusing. would you mind clearing it up. the way I understood it is the sender uses their private key to encrypt the message. then the sender uses the recipient's public key to encrypt the message? did I get that right? then that means the recipient would need decrypt the message twice??? 1st with their private key and then with the senders public key? does that sound right or did i misunderstand something? thanks
I watched 4 nuggets today to try to get this thru my thick scull and this was the best. Nice job, great visualization, but even with my speakers turned way up I still had a hard time hearing the audio
Yeah, this is one of my earlier videos before I realized I needed to get a better microphone. Sorry about the audio. I'm going to try to set aside time to record another version with better audio. Thanks for the feedback, Rob.
Hi, Pavan. You are correct based on they way you are stating it. However, the MiTM attack assumes that the sender has received the attacker's public key and encrypts their information with that key. That would mean that attacker would be able to decrypt the information with their private key and then re-encrypt with the intended recipient's private key. If the sender is using the intended recipient's public key, it is not possible to perform a MiTM attack without the attacker having a copy of the recipient's private key (as you stated).
@@PaulTurnerChannel Correction in your third sentence. "That would mean that attacker would be able to decrypt the information with their private key and then re-encrypt with the intended recipient's *PUBLIC* key."
Small pedantic point, but 2^128 doesn't "equate" to the number given. This is easy to see since the number given is divisible by 10 and hence by 5, but 2^128 is not. Of course, being off by a few million doesn't matter in this context!
DOH!!!!! Nice catch! Since calculators will automatically truncate, I looked online for it. Should have checked what I had found. You win the "'Way More Than Paying Attention" prize. I stand corrected, sir. And, appreciate you pointing it out. Thanks!
My best 18 mins spent on internet today. Thanks Sir..
Thanks for the feedback, Karthik. I'm glad it was helpful.
By far the best description of the certificate process I haver seen.....a fricken gem of a description!
Thank you very much for your feedback, Alex. I’m glad you liked it.
Finally a tutorial that explains the relationship between the public and private key. Thanks. So many videos take for granted that the public key is sent but in the end the private key magically decrypts 'somehow'. This makes it so much easier to understand.
Thanks for the feedback, Adam. I’m glad you found it helpful.
The best style of progression in teaching encryption concepts. Wow!
Thanks for the kind words, Ashwin. That means a lot to me.
The analogy with a safe that is being shipped around the world is great. Gave me a way better understanding of the topic!
I’m glad the analogy was helpful, K-San. I wish I could take credit for it but heard it somewhere else (can’t remember where) and found it very helpful as well. All the best.
One of the best videos on intro to crypto keys and certificates!
Thank you very much for the very nice comment!
The best explanation of Cryptography you will get via RUclips, you can take that to the bank!
Wow, Ricardo! I appreciate the very generous comment.
Very informative and clear. This is of the quality of paid resources. Thank you for sharing!
Thank you for your very kind comment, James. I’m glad you enjoyed it.
After days of searching on this topic this is, by a country mile, the best explanation of encryption I have come across. Paul, as someone who has run many training courses myself, you articulate difficult concepts exceptionally well. Andy.
Thank you for you kind words, Andy. I'm glad it was helpful and humbled by your comments.
This tutorial is worth a million dollars. Thank you Paul!
Wow, Jerry. That is quite a compliment. Thank you!
Spending time this morning tuning up on cryptography concepts, and loving that I can get the refresher from the guy who taught me everything I know about this. You are so good at this stuff. Miss our interactions. Hope you are well, my friend.
This is probably the best video I have watched on keys! (I've watched many and never understood it)
Thanks a bunch for that feedback, Ajay. It means a lot to me that it was helpful to you.
That's the beauty, you explained so clearly. Thank you.
I really appreciate the feedback, Harish.
the most intuitive explanation for general idea. hat off to you, Paul.
Thanks a bunch for the feedback, Mike!
You have a gift for turning a complex concept into a simple explanation!
Thanks you very much for your feedback not means a lot to me.
Learning PKI with this playlist in 2024 😁😁😁😁
Thank you Paul
This is literally is the last piece of the jigsaw I was looking for and where it all comes together in understanding pki and certificates.Videos of such crystal clear explanatory quality about intricate technical stuff are few and far between.You took it to a whole different level, especially the last part where I experienced an epiphany when you combined the challenge of confidentiality with sender authentication.Thanks a lot Paul and keep up the good work!
Thank you so much for the enthusiastic feedback. I really appreciate it and am so glad you found it of value!
Great tutorial Paul, showing step by step how secure communications evolved on the internet.
Really glad you liked it, Balaji! Thanks for the feedback.
great video. Very well explained for someone like me who doesn't have any cryptography background.
I’m really happy to hear it was helpful, Shashank. Thanks for the kind feedback.
The best explanation about Certificates and Key exchange. Thank you for your contribution.
Thank you very much for taking the time to write your comment, Gerardo. I’m glad you felt the explanation was helpful.
Great comforting voice and great explanation. Thank you
Thanks for the kind feedback, Bernard. I’ll have to tell my kids that someone thinks I have a comforting voice. They’ll likely be surprised 😲
Seriously, I do appreciate it!
Nice Lecture. I just wanted to add that Certificate contains Digital signature which is just an Encrypted Hash that can be decrypted using the public key(verifying the sender), and the integrity can be verified with the Hash. For more information on who signs it, who checks it, watch further the video series on PKI, very well explained here. Thanks, Paul.
Great comment, Siddharth. Thanks!
Despite numerous encryption videos no RUclips, I believe this is the clearest and succinct one to explain these concepts in such as short period of time...bravo~
That is quite a compliment, Michael. Thank you.
Thank you so much for this coherent explanation!! You're such a great teacher
Thank you very much, Shambalamba. I appreciate the feedback.
Absolutely beautiful ! Hands down the best tutorial seen !
Wow! Thank you for the great compliment, Ameya. I’m glad you liked.
Future Visitors, If youre like me, watched dozens of videos but coudnt understand the Asymetric Crytography, THIS VIDEO IS FOR YOU.
Thanks Paul Turner
Wow, Aditya. Thank you very much for the endorsement!
Very good explanation on the topic. Thank you for offering up this training for free.
Thank you very much, Retro. I’m glad it is helpful.
Thank you for this, Paul. By far the best explanation of the topic
Thank you for your kind words, LocoCioco. I’m glad it was helpful.
Absolutely beautiful . By far the best explanation of the topic.
Thank you for your kind words, Sama. I’m glad you found it helpful.
Excellent Video and great Effort Paul. As one of the comment already pointed out, I don't know even a paid training would be able to teach in such detailed manner. I appreciate your effort. Keep it up.
Selvakumar, thank you for the very generous comment and your encouragement to keep creating videos. It makes it all worth it.
A good explanation on Encryption and key management, thanks paul for the efforts, it valued to my knowledge.
I’m glad you found it valuable, Vasil. Thanks for the feedback.
Very clear and helpful. It's difficult to get a good grasp of these concepts if you're going into IT type of stuff but haven't studied something of that sort.
I’m glad it was helpful, Nicolai! Thanks for your feedback.
Thanks a lot, it recapped everything and refreshed all my older memory...
I’m glad it was a good refresher for you, Kamal. Thanks.
You are the best Paul Turner, well explained.
Thank you very much for the kind feedback, Mfundo. I'm glad it was helpful.
Very detailed and easy to understand explanation - thank you for taking time and effort to make this!
I appreciate you making the time to give your feedback, Sanjay. I’m glad you liked it.
Thanks Paul for this great video. You have a gift of explaining complicated concept with ease
Thank you very much for that feedback.
Wow - am not a security guy - and I feel like an expert now ;) So lucid and easy to understand - was struggling to understand these key management concepts earlier - Great Video Paul - keep up the great work.Thanks a ton!!
Thank you for the enthusiastic feedback, Sameer. It is so good to hear.
@@PaulTurnerChannel Al to काqqqq1qq@६q,
Excellent video! Many thanks for all the work to create the extremely helpful graphics.
Thanks for taking the time to leave a comment, Ezra. Years ago, a great mentor taught me that pictures are an important tool to facilitate understanding. Since then, I’ve enjoyed experimenting with PowerPoint to communicate concepts. I really do appreciate your feedback and wish you the best!
@@PaulTurnerChannel Same to you, sir!
really awesome analogies, love the teachings
Thank you, Last Bench. Glad you liked it.
Really Appreciate the simple way in which you explained the complex concept..
I’m glad you liked it, Smit. Thanks for taking the time to provide the feedback!
Indeed. Best 18 min of my day as well. Well done. Great images and description.
Thanks for the kind words, Doc. I really appreciate it.
I can not think of any way explaining this better. Thank you
Thanks a bunch for your comment, Karlheinz. I'm glad you liked it.
Excellent explanation with a nice illustrative diagrams and walk through.
Thank you very much for your feedback, Prash. I’m glad you liked it.
studying for my comptia security + and this has been very useful
I’m so glad to hear that, Poly. Good luck with the test and your career!
Best explanation. Very useful in understanding Keys and Certificates, Thanks
Thank you very much for the kind feedback, Avashesh!
explanation clear as glass.Thank you very much
Thank you, Naman!
All your videos are excellent and well thought out. Thank you!
I appreciate your feedback. It means a lot to hear that. I'm hoping to get time to do more soon. Again, thank you.
Best video explaining concepts of Public-key and private Key and certificate. Awesome explanation sir !!!
Thank you so much, Sachin. Sorry for the slow response. I'm glad you enjoyed the video.
great explanation!!! easy, crisp and concise...way to go!!!
Thank you very much for your kind comment. It is great to hear.
So good. You are a gifted communicator
Thanks, Bob. I appreciate the feedback.
amazing explanation, much appreciated
You deserve 100k likes for this article!!
Wow! Your comment is worth 100k likes. Thank you!
i love your wonderful and very patient approach you took to explain it, it is hard to simplify it because simplification and analogies can induce deeper questions on the actual logic of how the whole thing really fits together and how it actually operates, but you made a serious conceited effort nonetheless. Was anyone else here left with the question of "Why" the man in the middle is NOT able to resurface on the picture after the introduction of certificates ? I mean, the man in the middle simply has to wrap his public key with a {fake} certificate and he can certainly continue to perpetuate his illicit acts of mediating between the two parties ?? LOL, i know the answer but I just wonder if ANYONE else here had that question lurking in the back of their minds when suddenly the solution to eliminate the middleman was simply the introduction of a certificate whereby the public key is simply "wrapped" inside a certificate and "walla" . . the middleman is defeated just like that ?? did it strike ANYBODY else here as "No way, the middleman WILL certainly persist becuz he will simply fabricate a certificate and wrap his malicious public key inside that fabricated certificate so he will therefore PERSIST with or without the introduction of certificates" ?? Hahahahaha, LOL
Tebogo, thank you for making me laugh. You’re right that I simplified things for the sake of making the basic concepts (hopefully) easier to understand. It is possible for a MitM to mint a forged certificate but they have to do it from a CA that the relying party trusts. With the emergence of Let’s Encrypt, this has become easier, but the MitM still has to then compromise DNS or the legitimate server they’re trying to MitM to successfully get a rogue cert.
You bring up a good point about certs versus raw public keys, and the potential disadvantages of each. The explicit trust afforded by raw public keys (and self-signed certs, for that matter), makes MitM more difficult as long as you can reliably manage all of the trust relationships. SSH is a good example of this (where the weaknesses include users blindly accepting server public keys or authorized keys being left around forever). Certs can reduce the management headache but then thrust the trust into a smaller number of entities (CAs) that must be secured.
I loved the humor and the accompanying thought provoking points. Thanks a bunch.
Thank you very much. Explanation is very clear... It is the best...
I’m happy that it was helpful to you, Rakshith. Thank you for your comment.
Amazing, thanks a lot, please add another video for practice and testing for all scenarios...
Very educative video. Thanks
Thanks a bunch for the feedback! I’m glad it was helpful.
Super session Paul👍🏼
Thanks for this feedback, too!
Wow, that a clear and concise lecture. Thank you Paul!
I really appreciate the feedback, Benjamin. Thank you!
Very good video to understand why the certificates are used ?
Thank you for your feedback, Rakesh. I’m glad you found it helpful.
The best explanation I came across
I'm glad it was helpful. It took me a while to understand these topics. I was hoping to be able to explain it so that others wouldn't have to take so long. I really appreciate your feedback.
Amazing explanation. Thank you so much.
Thank you for the great feedback, Matheus. Sorry for the slow response.
Amazing explanation !!
Really glad you liked it, Zeid. Thanks for taking the time to comment.
Very clear! Soooo useful
Thank you, Henri. I lm very glad it was useful.
This explanation is superb.
Thanks for the feedback. I really appreciate it.
Wow! Very amazing and easy to understand video, thanks a lot.
Thanks a bunch for your feedback. Glad you liked it.
Awesome video Sir, Please post more. for beginners like us, its a great source of info.
Holy shit this blew my mind, that was very clear and useful!
LOL!!! I was in the middle of a call when the notification for this comment came in. I burst out laughing. Thanks for the laugh!
.day and 7
K
009
.u9
Nice explanation. Thanks.
Thanks, Sparsh. I’m glad you liked it.
Really Helpful Thanks and Good work Paul !
Thanks for taking the time to give me feedback, Abhay.
Awesome video, Thank you!
Very Very well done and explained. Thank you sir !
Mohammed, I'm very glad you liked it and appreciate your kind feedback. Thank you.
Clear and concise. THANKS!!
Thank you for the feedback, Don! I appreciate it.
As clear as crystal.
Thanks for the comment. Much appreciated.
Many Thanks, Paul! That's very helpful.
Thank you very much for the feedback! I appreciate it and am glad it was helpful.
👍👍- Awesome! Thanks!
Glad you liked it, Athikora. Thank you.
Great job!!!
I’m glad you found it helpful, Faruk. Thanks!
Awesome explanation
Thanks for feedback! I appreciate it.
This was very helpful in understand CAs ! Thank you so much!
Amazing video, thanks!
I’m really glad you liked it. Thanks for taking the time to comment.
this video is gem !
Thank you very much for the kind feedback, R K!
Easily the best explaination of symmetric/asymmetric encryption and an overview what certificates are for, on youtube.
Wow, thanks a bunch for the feedback, Georg. I'm glad you found it helpful.
great explanation! thank you
Thank you, Francisco!
Great job Paul, you've done an simple guide for a very complicated issue. But I have a question please, how 2 parties can exchange private keys ?
Hey, Rocky. Thanks for the kind feedback. In response to your question, the beauty of asymmetric cryptography is that private keys do not need to be shared (should not be shared). If Party A wants to send something confidential to Party B, they get a copy of Party B’s cert (public key), encrypt the information with that, and send the encrypted info. Party B decrypts it with their private key (no private key sharing needed). Alternatively, if Party A wants to authenticate a message that they’re sending to Party B, they encrypt it with their own (Party A’s) private key and send that message to Party B. Party B then confirms it came from Party A by decrypting it with Party A’s cert (public key). Again, no need to exchange private keys. Public keys are shared but private (secret) keys are not. Secret keys are typically only exchanged in symmetric crypto. I hope this makes sense. (I kept it simple up top but, to be clear, when authenticating, Party A encrypts a hash of the message with their private key.)
@@PaulTurnerChannel It is so clear now Paul, I really appreciate your time. Many thanks.
thanks so much!
Thank you for your appreciation, Jiacheng.
Thanks for the video. Very informative, I had a little bit of an idea but it’s good to get a good overview before implementing :)
Glad it was helpful. Thanks for the feedback.
This was great Paul. It would have been good if you had added "sender"/"receiver" in the diagrams
Thanks for the feedback. I’ll keep that in mind for future videos. I really appreciate it.
Thank you so much for sharing, It was really clear!
I’m very glad, Raul. Thank you for your comment.
Fantastic!
Thanks a lot for your feedback, Sreeram. I appreciate it.
The presentation doesn't state clearly that the subject's public key is the primary piece of information that the certificate provides and that all the other fields are provided to ensure the validity of this key: with a certificate, the public key is part of that certificate. Alice can now use this public key to decrypt the certificate signature, validate it and encrypt her own message to be sent to Bob.
Hi, Petroleum. Thanks for the feedback. The video was getting pretty long so I put more information about certificates in other videos, which are in my channel. However, it appears you already have a good grasp of the concepts.
very clear and clean video; just one question, at 15:12, how can the receiver decrypt the message with the received public key? from my understanding, public key is for encrypting only (not decrypting), while private key is for decrypting (and for encrypting too, if needed), am I wrong?
ok, maybe I got it;
the encryption/decryption function via public/private key can be used this way:
{plainmessage}---publickey--->{cryptedmessage}---privatekey--->{plainmessage}
as well as this other way:
{plainmessage}---privatekey--->{cryptedmessage}---publickey--->{plainmessage}
hence the authentication is a kind of reverse form of (indeed you stated "turn the asymmetric cryptography around" at 14:08) of asymmetric encryption for communication.
Thanks a bunch for the great question, and your follow up, which looks correct. My explanation in the video didn’t distinguish between public key algorithms but implies RSA. The RSA algorithm which provides the ability to encrypt/decrypt in both directions (for signing or confidentiality). DSA and ECDSA only allow for encryption with the private key and decryption with the public key (for signing). Diffie Hellman (DH) works yet another way, where both parties create key pairs and exchange their public keys to generate a symmetric session key (for confidentiality). I hope this doesn’t further confuse things for you but I thought I would provide a little more background.
Thanks for posting the comment, I had the same question. Some part of it is clear now from the reply of Paul. But still I doubt after 16:35 if both parties have public keys already exchanged then why some one will use his private key to encrypt and use an algorithm (like RSA) which can encrypt and decrypt using public key, instead both parties can stick to an algorithm where only private key can decrypt, in that case they can use their partner's public key to encrypt and and send data, and their partner will decrypt using their own private key. Sure I'm missing something.
Thanks for the explanation! Isn't it possible for the man in the middle to forge the certificate somehow?
Hi, Flavio. Good question. The client the application software for the user on the left) will only trust certificates that have been issued by certificate authorities (CAs) that it trusts. The man in the middle would need to get access the private key of one CAs that the client trusts in order to forge a certificate. My other videos on PKI help answer this question visually (instead of me attempting to answer in text). Can you please look at those and see if they answer your question? If not, send me another comment and I will attempt to explain in a response.
@@PaulTurnerChannel Thanks for the reply. Will check out those videos soon
I was wondering about the significance of certificates, you nailed it. Great video and I enjoyed watching it. Wondering what if the man in the middle spoofs the certificate that its been issued by the legit party. which body issues the certificate?
Hi, Vishnu. I may need you to clarify your question but I’ll try to provide an answer. An MITM can only succeed if the relying party (typically the party who initiated the connection) trusts the issuer of the certificate that the MITM presents. This means that the MITM can’t use a self-signed cert. Instead, they have to convince a CA trusted by the relying party to issue them a certificate with the identity of the subject of the cert (the party that the relying party is communicating with). This should be very difficult if the CA does sufficient due diligence. There have been cases where an MITM compromised the DNS account of the subject and was then able to get Let’s Encrypt to issue them a cert (since LE will issue a cert based on a DNS verification). I hope this helps. Please tell me if it doesn’t answer your question.
@@PaulTurnerChannel thanks Paul, this helps. I was able to listen to some of your videos which explains certificate issuance process as well
good video overall. everything was making total sense up until that very last scenario. that was kind of confusing. would you mind clearing it up. the way I understood it is the sender uses their private key to encrypt the message. then the sender uses the recipient's public key to encrypt the message? did I get that right? then that means the recipient would need decrypt the message twice??? 1st with their private key and then with the senders public key? does that sound right or did i misunderstand something? thanks
Hi, Max. You explained it perfectly. Thanks for reaching out and checking.
I watched 4 nuggets today to try to get this thru my thick scull and this was the best. Nice job, great visualization, but even with my speakers turned way up I still had a hard time hearing the audio
Yeah, this is one of my earlier videos before I realized I needed to get a better microphone. Sorry about the audio. I'm going to try to set aside time to record another version with better audio. Thanks for the feedback, Rob.
@11:33 How the man in the middle can decrypt the message with his private key? Isn't it possible only with the private key of the intended recepient?
Hi, Pavan. You are correct based on they way you are stating it. However, the MiTM attack assumes that the sender has received the attacker's public key and encrypts their information with that key. That would mean that attacker would be able to decrypt the information with their private key and then re-encrypt with the intended recipient's private key. If the sender is using the intended recipient's public key, it is not possible to perform a MiTM attack without the attacker having a copy of the recipient's private key (as you stated).
@@PaulTurnerChannel Correction in your third sentence. "That would mean that attacker would be able to decrypt the information with their private key and then re-encrypt with the intended recipient's *PUBLIC* key."
omg... awesome!!
Thanks for the enthusiast feedback, Vikas. It put a big smile on my face!
beautiful
Thank you, Devin. I appreciate the feedback.
Great explanation!
I've been slow in replying but thank you very much for your comment, rabbit.
excellent
Thank you, Raghul.
Small pedantic point, but 2^128 doesn't "equate" to the number given. This is easy to see since the number given is divisible by 10 and hence by 5, but 2^128 is not. Of course, being off by a few million doesn't matter in this context!
DOH!!!!! Nice catch! Since calculators will automatically truncate, I looked online for it. Should have checked what I had found. You win the "'Way More Than Paying Attention" prize. I stand corrected, sir. And, appreciate you pointing it out. Thanks!
Great video by the way!@@PaulTurnerChannel