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.
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!
Despite numerous encryption videos no UA-cam, I believe this is the clearest and succinct one to explain these concepts in such as short period of time...bravo~
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.
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.
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!!
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.
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.
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.)
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.
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, 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.
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 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).
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.
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
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."
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.
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.
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.
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.
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.
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).
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!
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.
Thank you for a great tutorial! Question - where do session encryption keys (or simply session keys) fit into all of this? I have heard the client only uses the public key to encrypt a self-generated session key (which only the server can decrypt, of course), which then both the server and the client will use to encrypt their data in that session. Is that somewhat accurate, if not oversimplified? If so, is it because encrypting and decrypting everything with the public/private keys would be significantly slower compared to using a simpler key aka the session key (assuming it's not compromised, of course)? Also, regardless of the use of session keys, wouldn't a MITM, while he can't decipher client's messages to the server without server's private key, nonetheless be able to do so with the messages sent by the server back to the client using the server's public key? (Because information encryption with one key private or public, can be decrypted with its counterpart i.e public or private.)
Thanks for the comment and question, Sunil. Good question. You are correct that a session key is used between a client and a server. The way that the session key is established depends on the algorithm that is used. If RSA is used, it is as you describe, where the client generates the session key, encrypts it with the server's public key, and sends the encrypted session key to the server. The server then decrypts it with their private key and then that session key is used for encrypting data sent in both directions (which applies to your question in the second paragraph). If Diffie-Hellman is used (as required by TLS 1.3), the session key is established through key agreement (using the Diffie-Hellman algorithm). The server's certificate is used to digitally sign the initial packets exchanged between the client and server to prove to the client that it is the server the client intends to communicate with. I hope this answers your question.
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.
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.
The best style of progression in teaching encryption concepts. Wow!
Thanks for the kind words, Ashwin. That means a lot to me.
The best explanation of Cryptography you will get via UA-cam, you can take that to the bank!
Wow, Ricardo! I appreciate the very generous comment.
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 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.
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.
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.
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.
Great tutorial Paul, showing step by step how secure communications evolved on the internet.
Really glad you liked it, Balaji! Thanks for the 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.
That's the beauty, you explained so clearly. Thank you.
I really appreciate the feedback, Harish.
Learning PKI with this playlist in 2024 😁😁😁😁
Thank you Paul
Absolutely beautiful ! Hands down the best tutorial seen !
Wow! Thank you for the great compliment, Ameya. I’m glad you liked.
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.
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!
Despite numerous encryption videos no UA-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.
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!
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.
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.
Absolutely beautiful . By far the best explanation of the topic.
Thank you for your kind words, Sama. I’m glad you found it helpful.
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!
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!
You are the best Paul Turner, well explained.
Thank you very much for the kind feedback, Mfundo. I'm glad it was 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.
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.
Excellent explanation with a nice illustrative diagrams and walk through.
Thank you very much for your feedback, Prash. I’m glad you liked it.
Thank you so much for this coherent explanation!! You're such a great teacher
Thank you very much, Shambalamba. I appreciate 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.
really awesome analogies, love the teachings
Thank you, Last Bench. 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!
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.
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 Paul for this great video. You have a gift of explaining complicated concept with ease
Thank you very much for that 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.
Super session Paul👍🏼
Thanks for this feedback, too!
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!
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.
Best explanation. Very useful in understanding Keys and Certificates, Thanks
Thank you very much for the kind feedback, Avashesh!
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.
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.
Thanks a lot, it recapped everything and refreshed all my older memory...
I’m glad it was a good refresher for you, Kamal. Thanks.
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.
You deserve 100k likes for this article!!
Wow! Your comment is worth 100k likes. Thank you!
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, that a clear and concise lecture. Thank you Paul!
I really appreciate the feedback, Benjamin. Thank you!
Amazing, thanks a lot, please add another video for practice and testing for all scenarios...
explanation clear as glass.Thank you very much
Thank you, Naman!
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!
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.
Very educative video. Thanks
Thanks a bunch for the feedback! I’m glad it was helpful.
amazing explanation, much appreciated
Really Helpful Thanks and Good work Paul !
Thanks for taking the time to give me feedback, Abhay.
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.
Very good video to understand why the certificates are used ?
Thank you for your feedback, Rakesh. I’m glad you found it helpful.
This explanation is superb.
Thanks for the feedback. I really appreciate it.
Awesome video Sir, Please post more. for beginners like us, its a great source of info.
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.
Wow! Very amazing and easy to understand video, thanks a lot.
Thanks a bunch for your feedback. Glad you liked it.
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.
Amazing explanation. Thank you so much.
Thank you for the great feedback, Matheus. Sorry for the slow response.
Nice explanation. Thanks.
Thanks, Sparsh. I’m glad you liked 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
Very Very well done and explained. Thank you sir !
Mohammed, I'm very glad you liked it and appreciate your kind feedback. Thank you.
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.
Very clear! Soooo useful
Thank you, Henri. I lm very glad it was useful.
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).
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.
Awesome explanation
Thanks for feedback! I appreciate it.
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
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
@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."
Awesome video, Thank you!
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.
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.
Clear and concise. THANKS!!
Thank you for the feedback, Don! I appreciate it.
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.
Great job!!!
I’m glad you found it helpful, Faruk. Thanks!
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
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
Many Thanks, Paul! That's very helpful.
Thank you very much for the feedback! I appreciate it and am glad it was helpful.
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!
As clear as crystal.
Thanks for the comment. Much appreciated.
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! thank you
Thank you, Francisco!
👍👍- Awesome! Thanks!
Glad you liked it, Athikora. Thank you.
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.
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
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
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.
Thank you for a great tutorial! Question - where do session encryption keys (or simply session keys) fit into all of this? I have heard the client only uses the public key to encrypt a self-generated session key (which only the server can decrypt, of course), which then both the server and the client will use to encrypt their data in that session. Is that somewhat accurate, if not oversimplified? If so, is it because encrypting and decrypting everything with the public/private keys would be significantly slower compared to using a simpler key aka the session key (assuming it's not compromised, of course)?
Also, regardless of the use of session keys, wouldn't a MITM, while he can't decipher client's messages to the server without server's private key, nonetheless be able to do so with the messages sent by the server back to the client using the server's public key? (Because information encryption with one key private or public, can be decrypted with its counterpart i.e public or private.)
Thanks for the comment and question, Sunil. Good question. You are correct that a session key is used between a client and a server. The way that the session key is established depends on the algorithm that is used. If RSA is used, it is as you describe, where the client generates the session key, encrypts it with the server's public key, and sends the encrypted session key to the server. The server then decrypts it with their private key and then that session key is used for encrypting data sent in both directions (which applies to your question in the second paragraph). If Diffie-Hellman is used (as required by TLS 1.3), the session key is established through key agreement (using the Diffie-Hellman algorithm). The server's certificate is used to digitally sign the initial packets exchanged between the client and server to prove to the client that it is the server the client intends to communicate with. I hope this answers your question.
@@PaulTurnerChannel Cool, that answers my question. Thank you, Paul!