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.
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.
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.
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!
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!
Despite numerous encryption videos no TH-cam, I believe this is the clearest and succinct one to explain these concepts in such as short period of time...bravo~
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!
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.
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.
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.
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!!
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. 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.
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.
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.)
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."
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.
Hi, Michael. Great question. I don’t cover session keys in the video (figured it was long enough already). Session keys are used to encrypt the data sent between the two sides in the second to last scenario (certificate for confidentiality). There are two ways that session keys would be generated in that scenario: 1) After the server sends its cert, the client generates a random key, encrypts it with the public key in the server’s cert, and sends the encrypted key to the server. The server decrypts it with their private key and the both sides derive the session key(s) from that exchanged key. 2) Both the client and server generate Diffie-Hellman key pairs and send each other their public keys and a random nonce. The DH algorithm is then used to create the same session key(s) on both sides. The server cert is only used to authenticate the server in this case. I keep hoping to find time to make one or two videos that explain this. Hope this helps.
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
Hmmm. You may need to a bit elaborate on that analogy, Brett. Salting typically helps with making it more difficult for someone to use a rainbow attack on a hashed password. It seems to you could relate that to the use of digital signatures using certificates, since the credentials are relatively protected in both instances (private key and password). However, the private key doesn’t need to be sent in any form for digital signatures. I’ll have to think about the relationship between the two a bit more. Please feel free to provide additional context and background. Not sure if you’ve had a chance to watch my video on hashes. I’d be interested in your thoughts on that. Thanks for your thought provoking comment.
@@PaulTurnerChannel I think my analogy was just wrong. I'm new to cryptography so I'm still trying to understand it. Salting would change the line of binary by adding a random value onto a password then hashing? With certificates the name wouldn't be added directly onto the variable of the key, correct? So the name would have no impact on the keys binary.
Thank you for the feedback, Avinash. Your question is a big one. Can you give me a little more detail about what specific area you're looking at (client certificates, TLS, etc.)? That will help me provide a better answer.
Thanks for this. But there's a little confusion at the end, where at one point, you have mentioned that encryption is done by sender's private key before sending to receipient. Not sure if I got it wrong.
Thanks for your inquiry. You did hear correctly about encrypting with the private key. However, that is not for confidentiality. It is for authentication. Also, it is not the entire message that is encrypted with the private key. The message is hashed and the resulting hash value is encrypted with the private key. For confidentiality, the recipient’s public key (typically from a certificate) is used for encryption (along with a symmetric key). If this still doesn’t make sense, please tell me an I will provide a more detailed answer. I’m working on a video about hashing that should help with this concept.
@@PaulTurnerChannel - Thanks a lot Paul. I have just started to learn cryptography. So, I am just beginning to understand encrypting the message using the recipients public key before sending it. I haven't come to hashing yet. I will be waiting for the hashing video. Thankyou 🙌 your videos are very helpful
Great video! Question: since the public and private key are just numbers related to each other based on an algorithm, can't an attacker generate the private key using the public key and use it to decrypt the message?
Sorry for my slow response, Prashanth. Public key algorithms are designed to make it very difficult to derive the private key if you only have the public key. The difficulty and method of determining the private key from the public depends on the algorithm (e.g., factoring for RSA) and the key length (e.g., it is more difficult to factor a 2048 bit key pair than a 512 bit key pair). So, the basic design and assumption of security for a public key algorithm is that you can give out your public key freely without risk of an attacker being able to derive the value of your private key. I hope this helps. If not, please do not hesitate to follow up with another question.
Hi Paul, great video, thanks. Just wondering, how can one get into a field like this? What education background do you need? It looks super interesting.
Thanks for the feedback and for your question. It is a good question. The first step is to begin to educate yourself. Fortunately, with the internet now there are lots of online resources for that. If you’re interested in enterprise key management, you might start with NIST 1800-16 (www.nccoe.nist.gov/sites/default/files/library/sp1800/tls-serv-cert-mgt-nist-sp1800-16b-final.pdf). Once you’ve educated yourself on some of the basics, there is strong demand for people who have a passion for this area, as it is not necessarily mainstream security (though you would think it would be).
Paul Turner : Very nice video. [Doubt] : Most browser has pre-installed CA public keys which are used to decrypt the CA certificate and get the public key of source. Now a hacker can steal the public key of server and then in the SSL handshake he can use server's public key to send a symmetric key. This is an identity theft. How is this being prevented in certificate model.
Shahzad, thanks for your comment. The CA certificate is not needed to get (decrypt) the public key from the server certificate. The server certificate is not encrypted. The CA cert is used to verify the signature on the server certificate (by decrypting the signature that was applied by the issuing CA). Please see my videos in the PKI playlist about certificate issuance and validation. They will help explain that process. Getting a copy of the server certificate doesn’t allow for identity theft. In order to perform identity theft, and attacker must either steal the private key of the server or trick a trusted CA into issuing them a certificate with the name of the server.
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.
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.
My best 18 mins spent on internet today. Thanks Sir..
Thanks for the feedback, Karthik. I'm glad it was helpful.
One of the best videos on intro to crypto keys and certificates!
Thank you very much for the very nice comment!
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.
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!
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.
the most intuitive explanation for general idea. hat off to you, Paul.
Thanks a bunch for the feedback, Mike!
Great tutorial Paul, showing step by step how secure communications evolved on the internet.
Really glad you liked it, Balaji! Thanks for the feedback.
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.
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.
That's the beauty, you explained so clearly. Thank you.
I really appreciate the feedback, Harish.
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.
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.
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.
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.
The best explanation of Cryptography you will get via TH-cam, you can take that to the bank!
Wow, Ricardo! I appreciate the very generous comment.
Absolutely beautiful ! Hands down the best tutorial seen !
Wow! Thank you for the great compliment, Ameya. I’m glad you liked.
Excellent explanation with a nice illustrative diagrams and walk through.
Thank you very much for your feedback, Prash. I’m glad you liked it.
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!
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!
You are the best Paul Turner, well explained.
Thank you very much for the kind feedback, Mfundo. I'm glad it was helpful.
Despite numerous encryption videos no TH-cam, 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.
Absolutely beautiful . By far the best explanation of the topic.
Thank you for your kind words, Sama. I’m glad you found it helpful.
Thank you so much for this coherent explanation!! You're such a great teacher
Thank you very much, Shambalamba. I appreciate the feedback.
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.
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.
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.
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!
Thanks Paul for this great video. You have a gift of explaining complicated concept with ease
Thank you very much for that feedback.
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.
Best explanation. Very useful in understanding Keys and Certificates, Thanks
Thank you very much for the kind feedback, Avashesh!
So good. You are a gifted communicator
Thanks, Bob. I appreciate 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.
Super session Paul👍🏼
Thanks for this feedback, too!
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.
really awesome analogies, love the teachings
Thank you, Last Bench. Glad you liked 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!
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.
great explanation!!! easy, crisp and concise...way to go!!!
Thank you very much for your kind comment. It is great to hear.
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,
Thanks a lot, it recapped everything and refreshed all my older memory...
I’m glad it was a good refresher for you, Kamal. Thanks.
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.
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!
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.
Very educative video. Thanks
Thanks a bunch for the feedback! I’m glad it was helpful.
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.
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 explanation !!
Really glad you liked it, Zeid. Thanks for taking the time to comment.
explanation clear as glass.Thank you very much
Thank you, Naman!
Wow! Very amazing and easy to understand video, thanks a lot.
Thanks a bunch for your feedback. Glad you liked it.
Really Helpful Thanks and Good work Paul !
Thanks for taking the time to give me feedback, Abhay.
Amazing, thanks a lot, please add another video for practice and testing for all scenarios...
This explanation is superb.
Thanks for the feedback. I really appreciate it.
amazing explanation, much appreciated
Learning PKI with this playlist in 2024 😁😁😁😁
Thank you Paul
Awesome explanation
Thanks for feedback! I appreciate it.
Awesome video Sir, Please post more. for beginners like us, its a great source of info.
You deserve 100k likes for this article!!
Wow! Your comment is worth 100k likes. Thank you!
Wow, that a clear and concise lecture. Thank you Paul!
I really appreciate the feedback, Benjamin. Thank you!
Nice explanation. Thanks.
Thanks, Sparsh. I’m glad you liked it.
Amazing explanation. Thank you so much.
Thank you for the great feedback, Matheus. Sorry for the slow response.
Very clear! Soooo useful
Thank you, Henri. I lm very glad it was useful.
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.
Great job!!!
I’m glad you found it helpful, Faruk. Thanks!
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!
Very Very well done and explained. Thank you sir !
Mohammed, I'm very glad you liked it and appreciate your kind feedback. 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.
Clear and concise. THANKS!!
Thank you for the feedback, Don! I appreciate it.
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
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!
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.
Awesome video, Thank you!
@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."
Amazing video, thanks!
I’m really glad you liked it. Thanks for taking the time to comment.
Many Thanks, Paul! That's very helpful.
Thank you very much for the feedback! I appreciate it and am glad it was helpful.
great explanation! thank you
Thank you, Francisco!
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
this video is gem !
Thank you very much for the kind feedback, R K!
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.
👍👍- Awesome! Thanks!
Glad you liked it, Athikora. Thank you.
Thank you so much for sharing, It was really clear!
I’m very glad, Raul. Thank you for your comment.
This was very helpful in understand CAs ! Thank you so much!
Great video. However how to session keys play a role in this scenario?
Hi, Michael. Great question. I don’t cover session keys in the video (figured it was long enough already). Session keys are used to encrypt the data sent between the two sides in the second to last scenario (certificate for confidentiality).
There are two ways that session keys would be generated in that scenario: 1) After the server sends its cert, the client generates a random key, encrypts it with the public key in the server’s cert, and sends the encrypted key to the server. The server decrypts it with their private key and the both sides derive the session key(s) from that exchanged key. 2) Both the client and server generate Diffie-Hellman key pairs and send each other their public keys and a random nonce. The DH algorithm is then used to create the same session key(s) on both sides. The server cert is only used to authenticate the server in this case.
I keep hoping to find time to make one or two videos that explain this. Hope this helps.
Paul Turner thank you so much
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.
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.
So certificates are like salting when hashing passwords?
Hmmm. You may need to a bit elaborate on that analogy, Brett. Salting typically helps with making it more difficult for someone to use a rainbow attack on a hashed password. It seems to you could relate that to the use of digital signatures using certificates, since the credentials are relatively protected in both instances (private key and password). However, the private key doesn’t need to be sent in any form for digital signatures. I’ll have to think about the relationship between the two a bit more. Please feel free to provide additional context and background. Not sure if you’ve had a chance to watch my video on hashes. I’d be interested in your thoughts on that. Thanks for your thought provoking comment.
@@PaulTurnerChannel I think my analogy was just wrong. I'm new to cryptography so I'm still trying to understand it. Salting would change the line of binary by adding a random value onto a password then hashing? With certificates the name wouldn't be added directly onto the variable of the key, correct? So the name would have no impact on the keys binary.
Great explanation!
I've been slow in replying but thank you very much for your comment, rabbit.
great video, any suggestions on how the certificates are published and distributed?
Thank you for the feedback, Avinash. Your question is a big one. Can you give me a little more detail about what specific area you're looking at (client certificates, TLS, etc.)? That will help me provide a better answer.
Thanks for this. But there's a little confusion at the end, where at one point, you have mentioned that encryption is done by sender's private key before sending to receipient. Not sure if I got it wrong.
Thanks for your inquiry. You did hear correctly about encrypting with the private key. However, that is not for confidentiality. It is for authentication. Also, it is not the entire message that is encrypted with the private key. The message is hashed and the resulting hash value is encrypted with the private key. For confidentiality, the recipient’s public key (typically from a certificate) is used for encryption (along with a symmetric key). If this still doesn’t make sense, please tell me an I will provide a more detailed answer. I’m working on a video about hashing that should help with this concept.
@@PaulTurnerChannel - Thanks a lot Paul. I have just started to learn cryptography. So, I am just beginning to understand encrypting the message using the recipients public key before sending it. I haven't come to hashing yet. I will be waiting for the hashing video. Thankyou 🙌 your videos are very helpful
Great video! Question: since the public and private key are just numbers related to each other based on an algorithm, can't an attacker generate the private key using the public key and use it to decrypt the message?
Sorry for my slow response, Prashanth. Public key algorithms are designed to make it very difficult to derive the private key if you only have the public key. The difficulty and method of determining the private key from the public depends on the algorithm (e.g., factoring for RSA) and the key length (e.g., it is more difficult to factor a 2048 bit key pair than a 512 bit key pair). So, the basic design and assumption of security for a public key algorithm is that you can give out your public key freely without risk of an attacker being able to derive the value of your private key. I hope this helps. If not, please do not hesitate to follow up with another question.
@@PaulTurnerChannel thank you so much Paul.i will subscribe and share.
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.
omg... awesome!!
Thanks for the enthusiast feedback, Vikas. It put a big smile on my face!
Hi Paul, great video, thanks. Just wondering, how can one get into a field like this? What education background do you need? It looks super interesting.
Thanks for the feedback and for your question. It is a good question. The first step is to begin to educate yourself. Fortunately, with the internet now there are lots of online resources for that. If you’re interested in enterprise key management, you might start with NIST 1800-16 (www.nccoe.nist.gov/sites/default/files/library/sp1800/tls-serv-cert-mgt-nist-sp1800-16b-final.pdf). Once you’ve educated yourself on some of the basics, there is strong demand for people who have a passion for this area, as it is not necessarily mainstream security (though you would think it would be).
Paul Turner : Very nice video. [Doubt] : Most browser has pre-installed CA public keys which are used to decrypt the CA certificate and get the public key of source. Now a hacker can steal the public key of server and then in the SSL handshake he can use server's public key to send a symmetric key. This is an identity theft. How is this being prevented in certificate model.
Shahzad, thanks for your comment. The CA certificate is not needed to get (decrypt) the public key from the server certificate. The server certificate is not encrypted. The CA cert is used to verify the signature on the server certificate (by decrypting the signature that was applied by the issuing CA). Please see my videos in the PKI playlist about certificate issuance and validation. They will help explain that process. Getting a copy of the server certificate doesn’t allow for identity theft. In order to perform identity theft, and attacker must either steal the private key of the server or trick a trusted CA into issuing them a certificate with the name of the server.
As clear as crystal.
Thanks for the comment. Much appreciated.
beautiful
Thank you, Devin. I appreciate the feedback.
excellent
Thank you, Raghul.