yeah right? i watched the computerphile explanation, and I didnt got it. I thought i wasnt paying enough attention, but now that I finally get it I can say that those guys made many mistakes in their video and didnt explained the topic correctly.
The best and simplest explanation ever on youtube for Diffie-Hellman key. No unnecessary maths symbols were used and the concept was explained with very simple example and to the point. This is the kind of teachers we wish to have in Colleges.
He is very good: 1) No Indian accent 2) very logical 3) He should say why the shared key is needed. The reason is that a and b have to have the same key to encrypt and decrypt 4) But they have to meet in a restaurant to share that key 5) Impractical 6) then they have to go through all these steps to arrive at the common key, 18 in this example Thank you, the best video on this topic
@@gustavogutierrez368 There is no secret key. The keys 'p' and 'g' are ok to be exposed. It is the secret values 'a' and 'b', which never are exchanged in between the client and the server, that gives the secrecy.
Here from Cyber Security and you explained it extremely well than my professor did or ever will. I'm just upset for the tuition I'm paying. Thanks a lot!!
Great stuff and easy understandable. Only thing I may not get was that Bulk encryption part. I've tried to google it but it seems to me like confusing term. Can somebody help me and explain me purpose of that? Thanks.
Great question Patrik! The bulk encryption is the encryption used by the client and server to send/receive messages during the session. In the TLS handshake, the purpose of the key exchange is to get a shared, symmetric encryption key for the client and server to use for the duration of the session. When we say "bulk encryption", we are referring to the symmetric encryption used by the client and server (typically AES). Here's a video on the TLS handshake that might help a little more: ua-cam.com/video/cuR05y_2Gxc/v-deo.html
Perfect! I was looking for a number example of how this works and you nailed it! Thank you for making the math clear, rather than just mixing paint... although the paint analogy makes the idea simple, it make the math side of it harder to understand. Sub well deserved
This glass drawing stuff is really clever. I thought at first he'd learned to write backwards, but they probably just flip the video, huh? Although, in that case, what about the text on the shirt?
I agree, he does these videos enough, he probably got a mirrored shirt to match. He's also writing with his left hand, which statistically means it is probably indeed flipped.
Great video, I have been confused on why is it impossible to decrypt a tcpdump trace with the TLS/SSL private key provided when HTTPS is encrypted using Perfect Forward Secrecy, now it all explains! thanks.
Mod is the modulo function, and it's a one-way function that takes the remainder of dividing two numbers as its result. It's a one-way function because you can't work backwards from the answer and figure out the numbers that were used to get the mod result...so it's only one way. The mod value in the Diffie Hellman tells you what number you divide by in order to get the result. So, in the example, the mod number is 23. So, you would take the first number and divide it by 23 and see what the remainder number is....that remainder is the result of the mod calculation. For example, if you have 17 mod 3, the calculation would be 17 / 3 = 5, remainder 2. So the answer to "17 mod 3" is 2. I hope this helps!
when we are sending "A" trough public everyone can easily decrypt it right? the formula is A=g^a mod P which for an eavesdropper looks like 4=5^x mod 23, well no matter how long the P is, with a proper computer "a" can be computed, so we have "a", and "B" is in the public too, so we just take these two and calculate 18 on our own. can someone explain to me what i'm missing?
Great question/observation! You are correct that the calculation for "a" and "b" would be fairly trivial if these numbers used in the video were actually used in real life. But, the power of this key exchange relies on using very large numbers for P, G, a, b, etc. When very large numbers are used, it becomes computationally very difficult to crack the encryption. Of course, along the way, computers have become more capable/powerful, so the key sizes of these encryption algorithms have also grown larger so as to stay ahead of the computer power. It's a back and forth game that will go on for a long time!
How do you use the key(s) to encrypt/decrypt a message? I ask because no one who explains DHKE explains the message encryption part. And when I look up how to encrypt messages I always find RSA, which starts out with the product of two prime numbers, and there is no bridge between these two concepts. You cant communicate the parameters to a receiver to build an RSA tunnel without compromising security.
Hi MarKac...great question! The number of bits in the shared key depends on the established cipher suite between the client and the server. Once the Diffie-Hellman key exchange is complete, then you have a shared key for symmetric encryption (typically using AES as the encryption algorithm). For many implementations of AES, a key size of 128 is used. In fact, I just checked the key size that UA-cam uses at the moment, and it's AES 128. Each site is configured according to their own needs, but many sites use AES 128. Hope this helps!
Those numbers are not leaking any info on the secret keys, they are just a common base to build up the shared secret then. One of the two calculates the two numbers and sends them to the other end. This is what i thought, might not be correct.
Great video ! Please could you explain how phase 1 and 2 work together by introducing all these components (DH, ESP etc.) and how the traffic passes and is manipulated through these the two phases thanks
Thank you, it is understandable. But the thing that confuse me, the attacker knows g and p then he generates his own secret as well. He will have A an B. So i can assume he acts as Alice for example and calculate the shared. Why Alice and Bob get exact the same while attacker not knowing that he knows A and B. Why his scercet does not work. He can also generate secret that give same A as Alice
Glad you enjoyed it. You are correct that the attacker will know G and P. But, in order to create the shared key, the attacker would need to know the private value generated by one of the users (Alice / Bob). Here's a good picture representation of what's going on and who can see all the different parts: i.stack.imgur.com/IPUgS.png If an attacker were to somehow maneuver to a "Man in the Middle" position (let's assume he's impersonating Alice), then he could derive his own private value and then generate a shared key with Bob. Let's say Alice is the client and Bob is the server in this example. Servers can request Client Authentication where the client has to send a valid certificate (signed by the Certificate Authority) and then the server knows the client is legitimate. If the attacker was in the middle, he wouldn't be able to send a valid certificate from Alice, so the server would then know the client is invalid. And, if the attacker is impersonating the server, the same thing happens...the server sends a certificate to prove its authenticity. The certificate would be signed by the Certificate Authority so if Alice received the certificate and it was modified in any way, she would get an error message saying the certificate is not valid (or has been modified). This entire discussion highlights the fact that many different things are in play when it comes to security of communication between client and server. The key exchange portion (Diffie-Hellman) is an important part, but it is only part of the overall picture. Hope this helps!
Hi Rocky2...great question! The Diffie-Hellman parameters are critical because if they aren't chosen properly, then either Diffie-Hellman won't work at all or it will be easy to break. The client and server typically rely on a random number generator (on their machine) to pick their secret values. The other parameter values are typically generated in advance and are agreed on by the client and server. Here's a document that shows some Diffie-Hellman "groups" that can be used: datatracker.ietf.org/doc/rfc3526/ This creates a situation where the random numbers generated by the client and server are very important, and it brings into play the importance of the random number generator...it needs to create truly random numbers because if someone could somehow guess the pattern that the random number generator is using, then they could guess the random numbers and then break the encryption. I hope this helps!
Brilliant explanation. Is this the same method used in IKE phase 1 of an IPsec tunnel? I'm guessing the secret values are the private keys and the shared values (A and B) are the public keys that are exchanged between the two peers? Please clarify, thank you!
Great question! IKE Phase 1 does several things to include: authenticate and protect the identities of the IPSec peers; negotiate a matching IKE SA policy between peers to protect the IKE exchange; perform an authenticated Diffie-Hellman exchange with the end result of having matching shared secret keys; set up a secure tunnel to negotiate IKE phase 2 parameters. So, the Diffie-Hellman key exchange is certainly used as part of IKE Phase 1, but it's not the only thing happening during IKE Phase 1. Here's more on IKE and IPSEC: www.ciscopress.com/articles/article.asp?p=25474&seqNum=7 Hope this helps!
Great explanation but I have a question. Wouldn't an eavesdropper be able to figure out little a? If they know that A = 4, g = 5 and p = 23. This gives 4 = 5^a mod(23) a = 22n+4, with n ≥ 0. The eavesdropper could then just brute force it with n = 0 and get a = 4 .
This is a great point, Christos! And, this is why it's so important to use large numbers when implementing Diffie-Hellman in real life :) The example I used in the video shows how it all works, but in real life you (or your computer) would use much larger numbers. And, that is the strength behind the key exchange algorithm...that it would take a very long time to brute force (or otherwise crack) these numbers. Thanks!
so he got A=4 by dividing the result of 5^4=3125 by 23 (the mod) which came up to be 135.869...If you round it up, I think you get 136. Then you multiply 136 with 23(the mod) and you get 3128, then you subtract that with 3125 to get A=3 (3128 - 3125=3). I don't understand how he got A=4 though. For B=10, it is exactly the same process. Someone verify if I did it correctly.
@@mahammedhagi98 You're calculating your powers wrong. 5 ^ 4 = 625. Then 625 / 23 = 27.1739... At this point you ALWAYS round DOWN, so 27. Now take the 23 that was used to divide 625 and multiply by 27 which equals 621. Finally, subtract 625 from 621 to get 4. As for the number for B: 1.) 5 ^ 3 = 125 2.) 125 / 23 = 5.4347... round down => 5 3.) 23 x 5 = 115 4.) 125 - 115 = 10
Very nice explained, but I wonder, if an adversary is able to listen to exchange from the beginning, he will have an equation with a single unknown value to decrypt, each side. For example, in our case, for A=g^a%p, the adversary has A, g, p. What blocks him from solving this equation and reaching to the secret value? It's the similar case for B.
Great question! Different software applications will handle this differently, but the outcome will be the same regardless of which application is used (Diffie Hellman keys will be generated). As an example, Microsoft uses function calls to a Cryptographic API that will generate the key values. Here's some documentation on how they do it: docs.microsoft.com/en-us/windows/win32/seccrypto/diffie-hellman-keys#generating-diffie-hellman-keys
Great question! Remember that the entire goal of the TLS handshake is to get a shared, symmetric key for both the client (browser) and the server. In order to do this, a key exchange takes place. There is more than one way to accomplish this key exchange, but the two primary methods are RSA and Diffie Hellman. The RSA key exchange has been shown to have some vulnerabilities along the way, so many applications are choosing to exchange keys using the Diffie Hellman method now. It's a more secure way of doing the key exchange. I hope this helps!
Hi Kumar...were you wanting to know the difference between Diffie-Hellman key exchange and SHA? I just wanted to clarify what your question is. Thanks!
very poor example, same as in wikipedia, mainly because the value that client sends is actually the same as it's secret key. a=A=4 and a better example could have been chosen.
ok, i am the bad guy, i have P,G and A & B,,, for example, p=23,g=5,A=4 , so 4= 5 to the power ? MOD 23 >>> easy a=4, so i got now a and b , i can get the last shared secret :D :D that depends on a very complex random generated number. !
This is the most well explained and best presented lecture I have seen on youtube, and I have watched many. Nice job.
glad you enjoyed it!
yeah right? i watched the computerphile explanation, and I didnt got it. I thought i wasnt paying enough attention, but now that I finally get it I can say that those guys made many mistakes in their video and didnt explained the topic correctly.
The best and simplest explanation ever on youtube for Diffie-Hellman key. No unnecessary maths symbols were used and the concept was explained with very simple example and to the point. This is the kind of teachers we wish to have in Colleges.
glad you enjoyed it!
He is very good:
1) No Indian accent
2) very logical
3) He should say why the shared key is needed.
The reason is that a and b have to have the same key to encrypt and decrypt
4) But they have to meet in a restaurant to share that key
5) Impractical
6) then they have to go through all these steps to arrive at the common key, 18 in this example
Thank you, the best video on this topic
How do they share the secret key?
@@gustavogutierrez368 There is no secret key. The keys 'p' and 'g' are ok to be exposed. It is the secret values 'a' and 'b', which never are exchanged in between the client and the server, that gives the secrecy.
Here from Cyber Security and you explained it extremely well than my professor did or ever will. I'm just upset for the tuition I'm paying. Thanks a lot!!
Glad you enjoyed it!
Watched so many videos and read quite few pages with an explanation... and finally, someone explained this really clearly ! good job
glad it was helpful!!
Pure and simple to the point and no stupid maths symbols. Professor should learn from you.
glad you enjoyed it!
Simple and straight to the point and no maths symbols involved . Professors should learn from you.
glad you enjoyed it!
now I know how Diffie Helman key exchange work! thank you so much, man
glad you enjoyed the video!
Awesome. All these days I was just hearing DHE DHE... around . Now I know what it actually is. Thank you.
Glad you found it helpful!
Makes it so easy to understand. Exceptional explanation.
glad you enjoyed it!
I love these videos; the math always blows my mind. It just, works. So beautiful.
We're glad you enjoy these and we appreciate the comment!
excellent explanation on diffie hellman key exchange.
Glad you enjoyed it!
that was the best explanation on the subject on youtube.
glad you enjoyed it!
I decided during lockdown I would understand the encryption techniques used all of the time. This has helped hugely. Thank you so much!
glad you enjoyed the video!
Very explanatory and i love it. When i was reading it from my pdf it was difficult for me to understand but here is been made very simple. Good job
Appreciate the comment and glad you enjoyed the video!
Great stuff and easy understandable. Only thing I may not get was that Bulk encryption part. I've tried to google it but it seems to me like confusing term. Can somebody help me and explain me purpose of that? Thanks.
Great question Patrik! The bulk encryption is the encryption used by the client and server to send/receive messages during the session. In the TLS handshake, the purpose of the key exchange is to get a shared, symmetric encryption key for the client and server to use for the duration of the session. When we say "bulk encryption", we are referring to the symmetric encryption used by the client and server (typically AES). Here's a video on the TLS handshake that might help a little more: ua-cam.com/video/cuR05y_2Gxc/v-deo.html
@@devcentral Fantastic! Thanks.
LoL my lecture took about 30min for this.... You just took 11min to explain it and It was so clear!! Thank You :)
Excellent video! I can't wait to watch your IKEv2 when it becomes available
Glad you enjoyed it!
Thank you so much. A lot easier to understand then the way my lecture tried to teach
glad you enjoyed it!
Thanks for a great, clear easy understandable explanation - very appreciated!
Glad you enjoyed it!
so simple explaining, but strong
glad you enjoyed it!
Thanks. Always helps to see it worked out.
Glad you enjoyed it!
Perfect!
I was looking for a number example of how this works and you nailed it!
Thank you for making the math clear, rather than just mixing paint... although the paint analogy makes the idea simple, it make the math side of it harder to understand.
Sub well deserved
Appreciate the comment and sub!! 🙂
Thank you. Amazing video, clear and practical, great job!
glad you enjoyed it!
This glass drawing stuff is really clever. I thought at first he'd learned to write backwards, but they probably just flip the video, huh? Although, in that case, what about the text on the shirt?
I want to know this too
maybe the shirt is flipped too just to make the video cooler?
they probably flipped the shirt in real
mirrors :)
I agree, he does these videos enough, he probably got a mirrored shirt to match.
He's also writing with his left hand, which statistically means it is probably indeed flipped.
Best explanation. Even computerphile didnt got this topic right. They made many mistakes in their video.
Mike Pound: *Am I a joke to you?*
Very easy to understand, thank you John!
glad you enjoyed it!
Congrats, really nice explanation..
glad you enjoyed it!
I like the nice touch with mirroring the logo on his shirt. Great video other than that too :)
glad you enjoyed it!
best explanation of the topic. helps in exam thanks
This is very useful for my CS degree. Thanks.
glad you enjoyed it...and good luck on the CS degree!
Absolutely brilliant work!
glad you enjoyed it!
Great video, I have been confused on why is it impossible to decrypt a tcpdump trace with the TLS/SSL private key provided when HTTPS is encrypted using Perfect Forward Secrecy, now it all explains! thanks.
Glad you enjoyed it!
Fantastic explanation. I appreciate it.
glad you enjoyed it!
I understand Diffie-Hellman, I'm just sitting here wondering if you made a mirrored shirt in order to make these videos.
jefftheworld why yes, yes we did!
@@JasonRahm You should definitely sell mirror shirts. I'd definitely buy one. ;p
What’s mod mean? And how do you calculates them?
Mod is the modulo function, and it's a one-way function that takes the remainder of dividing two numbers as its result. It's a one-way function because you can't work backwards from the answer and figure out the numbers that were used to get the mod result...so it's only one way. The mod value in the Diffie Hellman tells you what number you divide by in order to get the result. So, in the example, the mod number is 23. So, you would take the first number and divide it by 23 and see what the remainder number is....that remainder is the result of the mod calculation. For example, if you have 17 mod 3, the calculation would be 17 / 3 = 5, remainder 2. So the answer to "17 mod 3" is 2. I hope this helps!
Fantastic explanation! Truly appreciate your effort! Thank you..
glad you enjoyed it!
Couldn't subscribe fast enough. Thank you! :))
Thanks much and Welcome!!
when we are sending "A" trough public everyone can easily decrypt it right? the formula is A=g^a mod P which for an eavesdropper looks like 4=5^x mod 23, well no matter how long the P is, with a proper computer "a" can be computed,
so we have "a", and "B" is in the public too, so we just take these two and calculate 18 on our own.
can someone explain to me what i'm missing?
Great question/observation! You are correct that the calculation for "a" and "b" would be fairly trivial if these numbers used in the video were actually used in real life. But, the power of this key exchange relies on using very large numbers for P, G, a, b, etc. When very large numbers are used, it becomes computationally very difficult to crack the encryption. Of course, along the way, computers have become more capable/powerful, so the key sizes of these encryption algorithms have also grown larger so as to stay ahead of the computer power. It's a back and forth game that will go on for a long time!
@@devcentral right! Thanks for clarification
What if quantum computers can solve these DLP problems?
Great video John. Keep up the good work.
glad you enjoyed it!
How do you use the key(s) to encrypt/decrypt a message? I ask because no one who explains DHKE explains the message encryption part. And when I look up how to encrypt messages I always find RSA, which starts out with the product of two prime numbers, and there is no bridge between these two concepts. You cant communicate the parameters to a receiver to build an RSA tunnel without compromising security.
very nice. I wonder ~how many bits has this end shared key(session key) when I establish HTTPS session?
Hi MarKac...great question! The number of bits in the shared key depends on the established cipher suite between the client and the server. Once the Diffie-Hellman key exchange is complete, then you have a shared key for symmetric encryption (typically using AES as the encryption algorithm). For many implementations of AES, a key size of 128 is used. In fact, I just checked the key size that UA-cam uses at the moment, and it's AES 128. Each site is configured according to their own needs, but many sites use AES 128. Hope this helps!
very easy explained very well presented, thank you.
Glad you liked it and thanks for the comment!!
Great video! Quick question, how P and G are exchanged between the client and the server? Or how they come to agree those values?
Those numbers are not leaking any info on the secret keys, they are just a common base to build up the shared secret then. One of the two calculates the two numbers and sends them to the other end. This is what i thought, might not be correct.
Great video ! Please could you explain how phase 1 and 2 work together by introducing all these components (DH, ESP etc.) and how the traffic passes and is manipulated through these the two phases
thanks
Thank you so much! Best explanation!
Thanks! We appreciate the comment!!
Amazing application of the mathematics and thanks for the explanation, very cool!
glad you enjoyed it!
the "g" can vary from client/server from client1/server1?
Great question! Yes, the server sends the values for "g" and "p" to the client, so the values will vary from client/server to client1/server1. Thanks!
Still an awesome video. Thanks!
Thanks! we appreciate the comment!
Very clear and understandable
glad you enjoyed it!
Awesome explaination, thank you :)
Glad you enjoyed it!
Well explained sir. This really made my day!
Thank you, it is understandable. But the thing that confuse me, the attacker knows g and p then he generates his own secret as well. He will have A an B. So i can assume he acts as Alice for example and calculate the shared. Why Alice and Bob get exact the same while attacker not knowing that he knows A and B. Why his scercet does not work. He can also generate secret that give same A as Alice
Glad you enjoyed it. You are correct that the attacker will know G and P. But, in order to create the shared key, the attacker would need to know the private value generated by one of the users (Alice / Bob). Here's a good picture representation of what's going on and who can see all the different parts: i.stack.imgur.com/IPUgS.png
If an attacker were to somehow maneuver to a "Man in the Middle" position (let's assume he's impersonating Alice), then he could derive his own private value and then generate a shared key with Bob. Let's say Alice is the client and Bob is the server in this example. Servers can request Client Authentication where the client has to send a valid certificate (signed by the Certificate Authority) and then the server knows the client is legitimate. If the attacker was in the middle, he wouldn't be able to send a valid certificate from Alice, so the server would then know the client is invalid. And, if the attacker is impersonating the server, the same thing happens...the server sends a certificate to prove its authenticity. The certificate would be signed by the Certificate Authority so if Alice received the certificate and it was modified in any way, she would get an error message saying the certificate is not valid (or has been modified).
This entire discussion highlights the fact that many different things are in play when it comes to security of communication between client and server. The key exchange portion (Diffie-Hellman) is an important part, but it is only part of the overall picture. Hope this helps!
3:56 thank you based god 🙏
man I really think you so much for your great work. I learned a lot from you. May god bless you
thanks! glad you are enjoying the videos!
What happens if the parameter are badly chosen? Can you give an example?
Hi Rocky2...great question! The Diffie-Hellman parameters are critical because if they aren't chosen properly, then either Diffie-Hellman won't work at all or it will be easy to break. The client and server typically rely on a random number generator (on their machine) to pick their secret values. The other parameter values are typically generated in advance and are agreed on by the client and server. Here's a document that shows some Diffie-Hellman "groups" that can be used: datatracker.ietf.org/doc/rfc3526/
This creates a situation where the random numbers generated by the client and server are very important, and it brings into play the importance of the random number generator...it needs to create truly random numbers because if someone could somehow guess the pattern that the random number generator is using, then they could guess the random numbers and then break the encryption. I hope this helps!
@@devcentral Good explanation. Thanks
Thanks for clear explanation
Thanks and we appreciate the note!!
Brilliant explanation. Is this the same method used in IKE phase 1 of an IPsec tunnel? I'm guessing the secret values are the private keys and the shared values (A and B) are the public keys that are exchanged between the two peers? Please clarify, thank you!
Great question! IKE Phase 1 does several things to include: authenticate and protect the identities of the IPSec peers; negotiate a matching IKE SA policy between peers to protect the IKE exchange; perform an authenticated Diffie-Hellman exchange with the end result of having matching shared secret keys; set up a secure tunnel to negotiate IKE phase 2 parameters. So, the Diffie-Hellman key exchange is certainly used as part of IKE Phase 1, but it's not the only thing happening during IKE Phase 1. Here's more on IKE and IPSEC: www.ciscopress.com/articles/article.asp?p=25474&seqNum=7
Hope this helps!
Great explanation but I have a question.
Wouldn't an eavesdropper be able to figure out little a? If they know that A = 4, g = 5 and p = 23.
This gives 4 = 5^a mod(23)
a = 22n+4, with n ≥ 0. The eavesdropper could then just brute force it with n = 0 and get a = 4 .
This is a great point, Christos! And, this is why it's so important to use large numbers when implementing Diffie-Hellman in real life :)
The example I used in the video shows how it all works, but in real life you (or your computer) would use much larger numbers. And, that is the strength behind the key exchange algorithm...that it would take a very long time to brute force (or otherwise crack) these numbers. Thanks!
Did you really write "Client" and "Server" in reverse at 1:14?
Thank you so much for this. Just a concern, quick question how long the number Mod = p can we choose which is guaranteed to be most secured?
Typically the key size is 2,048 bits. This means that the number is 2,048 bits long...a very large number!!
How do you get A=4 and B=10. Are these given #'s or is it calculated? If so how?
so he got A=4 by dividing the result of 5^4=3125 by 23 (the mod) which came up to be 135.869...If you round it up, I think you get 136. Then you multiply 136 with 23(the mod) and you get 3128, then you subtract that with 3125 to get A=3 (3128 - 3125=3). I don't understand how he got A=4 though. For B=10, it is exactly the same process. Someone verify if I did it correctly.
@@mahammedhagi98 You're calculating your powers wrong. 5 ^ 4 = 625. Then 625 / 23 = 27.1739... At this point you ALWAYS round DOWN, so 27. Now take the 23 that was used to divide 625 and multiply by 27 which equals 621. Finally, subtract 625 from 621 to get 4.
As for the number for B:
1.) 5 ^ 3 = 125
2.) 125 / 23 = 5.4347... round down => 5
3.) 23 x 5 = 115
4.) 125 - 115 = 10
is your shirt logo backwards?
He is right handed.
what is a primitive root modulo of a prime number?
Very nice explained, but I wonder, if an adversary is able to listen to exchange from the beginning, he will have an equation with a single unknown value to decrypt, each side. For example, in our case, for A=g^a%p, the adversary has A, g, p. What blocks him from solving this equation and reaching to the secret value? It's the similar case for B.
there are multiple correct solutions for "a" for example (5^23 mod 23) = (5^4 mod 23) = 4
this is an amazing explanation. thanks for saving me.
Thanks Harsh...I'm glad you enjoyed the video!
Great explanation, wish I watched this in Uni woops
Thanks so much. Really clear explanation.
glad you enjoyed it!
How is "a" and "b" generated?
Randomly chosen numbers at 4:10
Great question! Different software applications will handle this differently, but the outcome will be the same regardless of which application is used (Diffie Hellman keys will be generated). As an example, Microsoft uses function calls to a Cryptographic API that will generate the key values. Here's some documentation on how they do it: docs.microsoft.com/en-us/windows/win32/seccrypto/diffie-hellman-keys#generating-diffie-hellman-keys
Thanks a lot for your explanation, nice one, I do have have question what is the difference between Diffie-Hellman and RSA?
You made it look like piece of cake. Thank you
Glad you enjoyed it!
Thank you! This is a video well done.
glad you enjoyed it!
You said before TLS does share key exchange.. why u need DH key exchange??
Great question! Remember that the entire goal of the TLS handshake is to get a shared, symmetric key for both the client (browser) and the server. In order to do this, a key exchange takes place. There is more than one way to accomplish this key exchange, but the two primary methods are RSA and Diffie Hellman. The RSA key exchange has been shown to have some vulnerabilities along the way, so many applications are choosing to exchange keys using the Diffie Hellman method now. It's a more secure way of doing the key exchange. I hope this helps!
Thanks. Great job.
glad you enjoyed it!
Why do we take primitive root and not random prime number?
Thanks so much
glad you enjoyed it!
can you explain me diffie-Hellman 4096bit to sha 256
Hi Kumar...were you wanting to know the difference between Diffie-Hellman key exchange and SHA? I just wanted to clarify what your question is. Thanks!
Thank you!
glad you enjoyed it!
explica como se explota amigo.
great video
Good content but turn the strobe effect off. You're the only person in 2019 with video latency that isn't caused by the viewer's internet connection.
🙌🏽🔥
thanks Man !
glad you enjoyed it!
great
Bro, you sound like you're out of breath. It's making me unconsciously hold my breath.
very poor example, same as in wikipedia, mainly because the value that client sends is actually the same as it's secret key. a=A=4 and a better example could have been chosen.
ok, i am the bad guy, i have P,G and A & B,,, for example, p=23,g=5,A=4 , so 4= 5 to the power ? MOD 23 >>> easy a=4, so i got now a and b , i can get the last shared secret :D :D
that depends on a very complex random generated number. !
Too much waffling
Not clear at all.
Hi Enrico...thanks for the comment. What about it was not clear, and maybe I can help clarify? Thanks!
@@devcentral Try to use simpler and less words.
@@Enrico-Migliore thanks...we will keep that in mind!