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.
Despite numerous encryption videos no CZcams, I believe this is the clearest and succinct one to explain these concepts in such as short period of time...bravo~
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.
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.
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.
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!
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 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!
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!
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.
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.
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.
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 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).
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
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.
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.
Hi Paul, This is the best video that I have come across on Keys & certificates. I have a doubt. How is the symmetric key generated? Is there any software/tool to generate the key? Thanks
Good question. A symmetric key is a randomly selected number. In order to "generate" (which really means select) a symmetric key, you want to have a trusted pseudo-random number generator (PRNG)--a program that selects a number in a random enough fashion so that it is difficult to guess. Though software developers could attempt to create their own PRNG, they typically rely on cryptographic libraries, such as OpenSSL or Windows CAPI/CNG, or hardware, such as an HSM or TPM chip. Consequently, when a symmetric key is needed, the program needing it will make a call to the cryptographic library asking for the key. The cryptographic library will use its PRNG functionality to randomly select a number and will return that to the calling program. If you're looking for something to generate random numbers, I believe OpenSSL or Windows CAPI/CNG are your best bet, depending on the platform and language you're using for your program. I hope that helps (and makes sense).
Can you please help us understanding where exactly chain certificate is involved in SSL handshake. I have concerns... what chain certificate does at server side. I understand what is chain certificate but my question is where you are making use of chain certificate in SSL handshake? Why we copy that on server when it not require in Ssl handshake. is there any specific use case of chain certificate Browsers have major root CAs and intermediate CAs public keys. Please correct if I am wrong, Whatever I see in the browser, those are not the root certificate and chain/intermediate certificate but they are only public keys of root and chain certs. Next, During the SSL handshake in step two when server responds to the client with his Server hello message.... After that does server send only server certificate or it sends both to the client (server certificate and chain certificate)? Please answer
Sorry for the VERY slow response, Kavita. Along with it's own server certificate, the server should return all of the CA certificates between the root and the server certificate to the client during the handshake (in the Certificate message that is sent along with the Server Hello portion of the handshake). The reason that it is a better practice for the server to return the CA certificates in the handshake instead of storing them in the client's trust store is that it provides better flexibility for changing CAs or even revoking CA certificates if a intermediate CA is compromised. This does require that CA certificates (the certificate chain) be loaded onto each TLS server (e.g., the web server). A lot of people forget to do this and find connection problems with their TLS clients to the servers. However, loading the CA certificates on servers is a lot easier than placing/maintaining them on each client. It is also possible to place CA chains on a single server and use an extension in the certificate called Authority Information Access (AIA) but it is possible that some TLS clients don't support this method of accessing CA certificates. To be clear (based on your question), the CA certificates provided by the server are used by the client the verify the signature on the server's certificate. The client starts with a CA certificate in its trust store (typically a root CA) and uses that to verify the signature on the next CA certificate in the chain, which is then used to verify the next CA certificate, and so on until it verifies the server certificates. You can see an explanation of this in czcams.com/video/lLw0dICMA_Y/video.html (though it only has one intermediate CA certificate in that example) I hope this helps. Please tell me if it doesn't make sense and I'll try again to explain differently. Again, sorry for being so slow to respond.
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."
Also, Can I interchangably use public key for private and vice versa event in case of encypting or decrypting or encrypting is something which only public or private key can and vice versa?
Shubham, Let me attempt to explain how encryption is used with public and private keys. First, it is important to understand that encryption with asymmetric cryptography (where public and private keys are used) is extremely slow. Encryption with public keys is used for confidentiality. If I’m going to send an encrypted message to another party, I will: 1) generate a symmetric key; 2) I encrypt the message I wish to send with the symmetric key; 3) encrypt the symmetric key with the public key of the intended recipient (typically retrieved from their certificate); and 4) send the encrypted message and encrypted symmetric key to the recipient. They then decrypt the symmetric key with their private key and decrypt the message with the symmetric key. Two parties can conduct a two way encrypted session by both using the symmetric key that was exchanged in the above example. Encryption with private keys is used for authentication. If I wish to digitally sign a message so that someone else knows it came from me. I will: 1) create a hash (message digest) of the message I’m going to send; 2) encrypt the hash of the message with the private key; and 3) send the message and encrypted hash to the intended recipient(s). The recipients can verify it came from me by: 1) creating a hash of the unencrypted message I sent (excluding the encrypted hash); 2) use my public key (again, typically pulled from my certificate) to decrypt the encrypted hash I sent; and 3) compare the hash they created with the one they just decrypted. If the two hashes match, they know that I encrypted the message with my private key (thus authenticating it came from me since I’m the only one who should have the private key matching that public key). I hope this answers your question. Please don’t hesitate to follow up with a question if I didn’t answer your inquiry.
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, 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.
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
My best 18 mins spent on internet today. Thanks Sir..
Thanks for the feedback, Karthik. I'm glad it was helpful.
amazing explanation, much appreciated
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.
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.
Absolutely beautiful ! Hands down the best tutorial seen !
Wow! Thank you for the great compliment, Ameya. I’m glad you liked.
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.
great explanation!!! easy, crisp and concise...way to go!!!
Thank you very much for your kind comment. It is great to hear.
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.
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.
the most intuitive explanation for general idea. hat off to you, Paul.
Thanks a bunch for the feedback, Mike!
Thanks Paul for this great video. You have a gift of explaining complicated concept with ease
Thank you very much for that feedback.
This tutorial is worth a million dollars. Thank you Paul!
Wow, Jerry. That is quite a compliment. 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.
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.
That's the beauty, you explained so clearly. Thank you.
I really appreciate the feedback, Harish.
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.
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 CZcams, 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.
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.
This was very helpful in understand CAs ! Thank you so much!
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 a lot, it recapped everything and refreshed all my older memory...
I’m glad it was a good refresher for you, Kamal. Thanks.
The best style of progression in teaching encryption concepts. Wow!
Thanks for the kind words, Ashwin. That means a lot to me.
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.
Awesome video Sir, Please post more. for beginners like us, its a great source of info.
Great tutorial Paul, showing step by step how secure communications evolved on the internet.
Really glad you liked it, Balaji! Thanks for the feedback.
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.
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.
Absolutely beautiful . By far the best explanation of the topic.
Thank you for your kind words, Sama. I’m glad you found it helpful.
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.
Many Thanks, Paul! That's very helpful.
Thank you very much for the feedback! I appreciate it and am glad it was helpful.
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!
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.
Wow, that a clear and concise lecture. Thank you Paul!
I really appreciate the feedback, Benjamin. Thank you!
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.
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,
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!
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!
Clear and concise. THANKS!!
Thank you for the feedback, Don! I appreciate 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.
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.
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.
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
really awesome analogies, love the teachings
Thank you, Last Bench. Glad you liked it.
Wow! Very amazing and easy to understand video, thanks a lot.
Thanks a bunch for your feedback. 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!
The best explanation of Cryptography you will get via CZcams, you can take that to the bank!
Wow, Ricardo! I appreciate the very generous comment.
Very Very well done and explained. Thank you sir !
Mohammed, I'm very glad you liked it and appreciate your kind feedback. Thank you.
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.
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!
Really Helpful Thanks and Good work Paul !
Thanks for taking the time to give me feedback, Abhay.
Excellent explanation with a nice illustrative diagrams and walk through.
Thank you very much for your feedback, Prash. I’m glad you liked it.
Amazing, thanks a lot, please add another video for practice and testing for all scenarios...
Best explanation. Very useful in understanding Keys and Certificates, Thanks
Thank you very much for the kind feedback, Avashesh!
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.
Awesome video, Thank you!
Amazing explanation. Thank you so much.
Thank you for the great feedback, Matheus. Sorry for the slow response.
explanation clear as glass.Thank you very much
Thank you, Naman!
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.
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.
Thank you so much for sharing, It was really clear!
I’m very glad, Raul. Thank you for your comment.
So good. You are a gifted communicator
Thanks, Bob. I appreciate the feedback.
You deserve 100k likes for this article!!
Wow! Your comment is worth 100k likes. Thank you!
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 clear! Soooo useful
Thank you, Henri. I lm very glad it was useful.
Amazing explanation !!
Really glad you liked it, Zeid. Thanks for taking the time to comment.
This explanation is superb.
Thanks for the feedback. I really appreciate it.
Amazing video, thanks!
I’m really glad you liked it. Thanks for taking the time to comment.
great explanation! thank you
Thank you, Francisco!
Super session Paul👍🏼
Thanks for this feedback, too!
Nice explanation. Thanks.
Thanks, Sparsh. I’m glad you liked it.
thanks for the video !
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 educative video. Thanks
Thanks a bunch for the feedback! I’m glad it was helpful.
👍👍- Awesome! Thanks!
Glad you liked it, Athikora. Thank you.
Great explanation!
I've been slow in replying but thank you very much for your comment, rabbit.
Great job!!!
I’m glad you found it helpful, Faruk. Thanks!
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.
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.
Awesome explanation
Thanks for feedback! I appreciate it.
omg... awesome!!
Thanks for the enthusiast feedback, Vikas. It put a big smile on my face!
Fantastic!
Thanks a lot for your feedback, Sreeram. I appreciate it.
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).
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.
AWESOME!
Thanks for the feedback, Atul. I'm glad you liked it.
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.
Excellent!!.
Thank you, Velmurugan. I appreciate the feedback.
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.
Hi Paul,
This is the best video that I have come across on Keys & certificates.
I have a doubt. How is the symmetric key generated? Is there any software/tool to generate the key?
Thanks
Good question. A symmetric key is a randomly selected number. In order to "generate" (which really means select) a symmetric key, you want to have a trusted pseudo-random number generator (PRNG)--a program that selects a number in a random enough fashion so that it is difficult to guess. Though software developers could attempt to create their own PRNG, they typically rely on cryptographic libraries, such as OpenSSL or Windows CAPI/CNG, or hardware, such as an HSM or TPM chip. Consequently, when a symmetric key is needed, the program needing it will make a call to the cryptographic library asking for the key. The cryptographic library will use its PRNG functionality to randomly select a number and will return that to the calling program.
If you're looking for something to generate random numbers, I believe OpenSSL or Windows CAPI/CNG are your best bet, depending on the platform and language you're using for your program.
I hope that helps (and makes sense).
Thank you
Can you please help us understanding where exactly chain certificate is involved in SSL handshake. I have concerns... what chain certificate does at server side. I understand what is chain certificate but my question is where you are making use of chain certificate in SSL handshake?
Why we copy that on server when it not require in Ssl handshake. is there any specific use case of chain certificate
Browsers have major root CAs and intermediate CAs public keys. Please correct if I am wrong, Whatever I see in the browser, those are not the root certificate and chain/intermediate certificate but they are only public keys of root and chain certs. Next, During the SSL handshake in step two when server responds to the client with his Server hello message.... After that does server send only server certificate or it sends both to the client (server certificate and chain certificate)? Please answer
Sorry for the VERY slow response, Kavita. Along with it's own server certificate, the server should return all of the CA certificates between the root and the server certificate to the client during the handshake (in the Certificate message that is sent along with the Server Hello portion of the handshake). The reason that it is a better practice for the server to return the CA certificates in the handshake instead of storing them in the client's trust store is that it provides better flexibility for changing CAs or even revoking CA certificates if a intermediate CA is compromised. This does require that CA certificates (the certificate chain) be loaded onto each TLS server (e.g., the web server).
A lot of people forget to do this and find connection problems with their TLS clients to the servers. However, loading the CA certificates on servers is a lot easier than placing/maintaining them on each client. It is also possible to place CA chains on a single server and use an extension in the certificate called Authority Information Access (AIA) but it is possible that some TLS clients don't support this method of accessing CA certificates.
To be clear (based on your question), the CA certificates provided by the server are used by the client the verify the signature on the server's certificate. The client starts with a CA certificate in its trust store (typically a root CA) and uses that to verify the signature on the next CA certificate in the chain, which is then used to verify the next CA certificate, and so on until it verifies the server certificates. You can see an explanation of this in czcams.com/video/lLw0dICMA_Y/video.html (though it only has one intermediate CA certificate in that example)
I hope this helps. Please tell me if it doesn't make sense and I'll try again to explain differently. Again, sorry for being so slow to respond.
@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."
Also, Can I interchangably use public key for private and vice versa event in case of encypting or decrypting or encrypting is something which only public or private key can and vice versa?
Shubham, Let me attempt to explain how encryption is used with public and private keys. First, it is important to understand that encryption with asymmetric cryptography (where public and private keys are used) is extremely slow.
Encryption with public keys is used for confidentiality. If I’m going to send an encrypted message to another party, I will: 1) generate a symmetric key; 2) I encrypt the message I wish to send with the symmetric key; 3) encrypt the symmetric key with the public key of the intended recipient (typically retrieved from their certificate); and 4) send the encrypted message and encrypted symmetric key to the recipient. They then decrypt the symmetric key with their private key and decrypt the message with the symmetric key. Two parties can conduct a two way encrypted session by both using the symmetric key that was exchanged in the above example.
Encryption with private keys is used for authentication. If I wish to digitally sign a message so that someone else knows it came from me. I will: 1) create a hash (message digest) of the message I’m going to send; 2) encrypt the hash of the message with the private key; and 3) send the message and encrypted hash to the intended recipient(s). The recipients can verify it came from me by: 1) creating a hash of the unencrypted message I sent (excluding the encrypted hash); 2) use my public key (again, typically pulled from my certificate) to decrypt the encrypted hash I sent; and 3) compare the hash they created with the one they just decrypted. If the two hashes match, they know that I encrypted the message with my private key (thus authenticating it came from me since I’m the only one who should have the private key matching that public key).
I hope this answers your question. Please don’t hesitate to follow up with a question if I didn’t answer your inquiry.
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.
Helpful !
Very good video to understand why the certificates are used ?
Thank you for your feedback, Rakesh. I’m glad you found it helpful.
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
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