RSA key exchange is fully susceptible by man in the middle as well. Sean has a private key and signs the data with its own key. Alice cannot know wether the data was encrypted and signed by Sean (man in the middle) or Bob since the real identity cannot be verified by an external authority. This is why we have certificates. SSL is what websites (HTTPS) are using to implement the whole chain of security features to finally become secure against man in the middle attacks. The final step that SSL does ontop of RSA key exchange is to verify the public key with the certificate that server sent to the client upon SSL negotiation, using a global certificate store. In short, certificates themself have to be signed by a certificate authority, which (typically) can only be modified by Windows Updates (for Windows) and alike. The certificates for HTTPS include the domain name in it's ServerName property to restrict the usage of the certificate to a particular website. The browser will make sure to verify this. I think this should have been mentioned in the video before people run off and use RSA by itself when it really isn't secure against man in the middle (but it is secure against capturing of the data where it is not re-encrypted). Side note, SSL includes all above mentioned features (configurable). If you're interested in playing around with this in programming, try out the OpenSSL library. Also HTTPS is typically using an SSL library such as OpenSSL. For example, Chrome uses "boringssl" which is a library 'forked' from (based on) OpenSSL.
@YASH TRIVEDI Sorry for an extrodinarily late reply. I meant that RSA is secure against someone merely viewing the encrypted data. The RSA handshake has to be intercepted and new public/private key has to be generated in order to read (and potentially modify) the content. But this is what the certification process prevents.
I am taking network security class in college and this video explore a little more in depth of what I have learned so far. Very satisfied all the works from computerphile. :)
Forgot to mention the necessity of being able to safely share the public key, otherwise Sean could just nab that as well and do the same attack (why yes, I am Bob! You can verify that by checking me against the public key I just sent you!) That's where things like certificate authorities come in -- a (hopefully) trusted third party that can retain Bob's public key for him such that he doesn't have to send it to Alice himself and therefore Sean has no chance to inject himself into the conversation. Of course, that just punts the problem up a level: How can you trust that Bob's public key actually came from the CA? If Sean is operating at Alice's end of the connection, he could potentially intercept communication to the CA server as well as to Bob. As far as I know (and I might not be entirely accurate here..) this is resolved primarily by your OS and/or browser having a built-in list of trusted CAs (and we just assume that Sean hasn't been able to hack her browser or OS install.. if he had that level of access to Alice's machine, the whole question is moot anyway since he could just install a keylogger or whatever and capture the session directly.) So the CA send Bob's public key and authenticates themselves using their private key.. Alice can then use the CA's public key that she has stored locally to verify them, allowing her to safely retrieve Bob's public key and in turn use that to verify Bob. But that means trusting the CA (in the social sense, rather than the computational sense.) There was one big one from China this past year.. maybe 2..? that Google removed from Chrome's trusted list and the other major browsers slowly followed suit, because the CA wasn't acting trustworthy and could have potentially compromised security by double-issuing certificates and back-dating expiry dates and things like that. For the most part though, that's not a huge problem since CAs are basically out of business when the browsers stop trusting them -- meaning they have a huge incentive to play by the rules and those that don't won't matter for long either way.
I’ve watched most of this stuff on encryption and I don’t fully understand it, but this chap is brilliant at explaining what is going on plus the pros/cons of each system. Engrossing.
Not only does RSA hope that your private key doesn't get leaked, it also needs to assume that only Bob can get an RSA key pair for his domain name. Anyways, great video guys!
I create RSA for staff001.vpn.client_company_name_or_any_other_domain_that_I_want. My VPN only trusts my own CA. Create any domain that you like; unless you compromise my CA you are not getting in. (I also my Customer CA signing keys automatically roll on a monthly basis.)
Great video. Understanding these sort of key exchanges and realising how they can be broken by a Man in the Middle attack like this shows just what a huge security problem Superfish was (and probably still is on some computers). If you haven't seen it, look for the Computerphile video with Tom Scott from 2015 called "Man in the Middle Attacks & Superfish".
The best part of this video is when the interviewer says, "Diffie Hellman is dead in the water" and Dr. Mike Pound(with the most hilarious expression says, "Diffie Hellman is in REAL TROUBLE HERE!" I couldn't stop laughing and laughing! Awesome video.
OK, so... We use RSA to verify your identity versus a database of public keys, in order use Diffie-Hellman to make a short-lived shared key, all to send a one-time private key for use with AES for the final communication. I love it!
Root certificates are a whole other can of worms... There's a bunch of problems with it, but it gets kinda complex and I'm not a good person for explaining that... The Certificate issuing authorities are the heart of the problem in any event.
Well here's a basic explanation. TLS guarantees the authenticity, Alice will know the key is Bob's public key because Sean cannot sign a certificate tied to his key that will be acknowledged by a certificate authority.
+Kuralthes +Safety Certification Authorities, Root Certification Authorities and the Chain of Trust are not so much a mess, as much as they are simply *flawed* . Rather than rejecting the system outright because it doesn't perfectly defend against *every* conceivable attack, it should instead be a reminder that *NO* security mechanism is completely impervious to attacks -- especially not to attacks involving Human Error.
I discovered this channel a few days ago and I am already addicted to it... I have watched a dozen of your videos already and I liked each and every single one. All the computerphile team has a gift, I wish I could explain things the way you do. One question came to my mind while watching this particular video though: After having watched this video it is clear why, even with the server's public key, an extra "final" key is needed (the one that is going to be used to encrypt the requests and the requests and the responses before the transmission) using the DH key "exchange" (I used the quotes because in another video it is very well explained that this key is not really exchanged but generated at both sides equally instead). But the generation of this key has a computing cost at both sides, especially at the server side which needs to generate DH symmetric keys for all clients that are connected to it. My question then is: wouldn't it be better that, instead of using DH, the client generated not a random symmetric key - not a good idea in case the server certificate's private key gets compromised, as it is explained in this video - but a random pair of private/public asymmetric keys and sent the public one to the server? (just keys, not certificates, no need to check any certification validity at this level), so the protocol would look something like 1) client -> hello -> server 2) server -> certificate with public key -> client 3) client - checks the certification's validity and, if valid, generates a random pair of private/public keys 4) client -> client's public key from step 3 encrypted with the server's public key from step 2 -> server 5) server -> confirmation message encrypted with the server's private key (authenticity layer) + client's public key (confidentiality layer) -> client 6) client - checks that the message from step 5 can be decrypted (this would confirm that its public key has really reached the server). 7) client -> data request, encrypted with client's private key in 1st place (authenticity) + server's public key (confidentiality) -> server 8) server -> requested data, encrypted with server's private key (auth.) and client's public one (conf.) -> client The benefit I see in this approach is that the cost of generating "final" asymmetric keys, even though it is going to be probably higher than using the DH process (maybe even higher than twice - the sum of the server's and the client's costs in DH), relies completely on the clients and this would give some rest to the server, which is the one that suffers the most. In case these keys generation part would take "too long" for the client, the keys generation could start asynchronously at the same time that the hello message is sent at step 1, and step 4 would have to wait until the client's keys are completed; of course, only if the server's certificate has been verified... but even if the server's certificate is not valid, that pair of keys could still be used/recycled by the client in a different session/web (even with a different server), so their generation would not be a waste of computing power, and would make the process faster for that other session - this would need a thorough testing by the client's developer to make sure that a pair of random keys is not erroneously flagged as "still-usable" (once assigned to a session, they should NOT be used by another one). Maybe this is all madness... but your videos made my imagination fly 😅
Strictly speaking, it's not RSA that rescues it, but A's existing knowledge of B's public key. Otherwise, the network can step in and say "I''m the server you requested, and this is my public key," and you have gotten nowhere. Usually, it is some certificate authority that is built into the browser. But the point is there needs to be a public key that the man in the middle can't lie about.
I’m starting with the man in the middle I’m asking him to change his ways And no message could have been any clearer If you wanna make the world a better place Take a look at yourself, and then make a change
This video sidesteps a very important problem. How do I know I have Bob’s public key? For example, when Alice asks for Bob’s key, Sean can intercept that and send his own key, masquerading as Bob. You only pushed the problem one step down the stairs.
Depends on the implementation. * In case of the browser, there is a whole "SSL/TLS certificate" scheme, where the root cert you used to verify is already installed on your computer (by Google, Microsoft, Apple, or Mozilla). * In case of SSH, you store the PK from first visit. * In case of random apps, they either piggyback off the SSL/TLS certificate system, or just carry their own public key cert with them in the app for verification.
In the certification, the identification (among other things) is signed by the certfication authoritie, So alice will know she got Sean certificate and not Bobs
Yes, but couldn't he decrypt the message from Bob with Bob's public key, encrypt it with is own private key and intercept the message where Alice trys to get Bob's public key und send his own instead?
the scenario he explains is when the bob and alice already trust each other (they communicated before and alice knows bobs public key), but what about when a connection is being established for the first time (bob has to give his public key to alice)? is man in middle possible still?
The actual problem with using RSA for encryption of large amounts of information, like webpages and files instead of just key hashes, is that the larger the amount of information, the longer the calculation takes, so it's not efficient. Assymmetric encryption algorithms can take up to 2000x longer than symmetric encryption to encrypt and decrypt
The digital signature doesn't stop the man-in-the-middle attack because the attacker can gain access to the public key for decryption. I mean both Alice and Bob can realize that their communication have been intercepted but if Bob in that scenario sends something important right from the very start, that's basically it
The public key is not to keep the message secret, it is only to show that Bob sent the message that says it came from Bob. Only he can sign the message with his private key, so any message that is de-signable with his public key definitely came from him. A man in the middle can learn what (g^a)%n and (g^b)%n are, but as we learned in the other videos, that isn't enough to decrypt the traffic
If there are no certificates involved (like SSH), this will only work if the first exchange is safe, right? From what I understood, if the first exchange is compromised then the following ones will be too. Can someone please give me some insight?
What's to stop Sean doing the same man-in the middle attack on the private/public keys? It would require an out-of-band secure communication for Alice and Bob to know the true public key of each other.
i think it needs more details? because people will assume that as long as you are the man in the middle at the start! you can still decrypt and get all the messages and just pretend to be bob, you couldnt jump in half way through for sure with this explanation, but you forgot to mention that certificate authorities give pre installed keys to peoples computers so that the initial handshake doesnt get hijacked. that is explained in a previous video as i remember
How RSA is preventing from MITM? MITM is not only about changing a message but also about reading it. So in presented scenario Shaun can still reads what Bob is sending to Alice and vice versa, as Bob in only signing a message, not encrypting it.
One other problem that we would face if we only use RSA for sharing secret key would be that we would need public key of Alice (client) to encrypt the secret key. And in almost all the cases of web traffic, only servers have digital certificates, not the client.
Normally as a client you'd have access to your server's public key, and Alice will send her message encrypted with the server public key so only your server will be able to decryped it, and same on the way back. When it comes to other services, you have a certificate authorities to verify the server Alice is talking to is really who it claims to be.
Wait, what stops Sean from doing the exact same? He could generate his own public and private key pair and tell Alice that his public key is Bob's public key. Now Alyce will use Sean's public key for verification purposes!
For that, we have certificate providers. Usually all of our devices are preloaded with a certificate from a certificate provider (there's actually several preloaded). Ordinarily, Bob goes to the certificate provider and asks them to sign Bob's public key. When Bob sends the public key, Alice uses the certificate provider's public key to see if the public key that Bob sent is actually Bob. If not, then they know something's off. In this case, your browser would give a giant red warning.
As far as I understand Server sends the G, N and G^random signed with servers private key and sends along with the server certificate to client, once the client verifies the authenticity using PKI and he will send his G^random and encrypts this using servers public key. Thus they will both arrive at the shared secret key using DH with RSA. These keys are ephemeral, i.e a new key pair is generated for every new session with the server.
This breaks if Sean is making modification while Alice and Bob are exchanging public keys. Sean can listen to Alice sending her public key (AlicePub) to Bob and instead of letting that public key reach Bob, he can send his own public key (SeanPub1) to Bob. Now Bob will sign the message containing Bob's public key (BobPub) using what he falsely believes to be Alice's public key (SeanPub1) and try sending it to Alice. Sean, man in the middle, then can decrypt the message and send another public key (SeanPub2) to Alice. In this way Bob successfully deceived Alice and Bob about each other's public keys.
I think there is an error in the animation. When Alice generate a key a, she debts out g^a, not g*a. And when bob send message back to Alice, bob debts out g^(ab) not g*a*b.
What do you think of this scheme: say a user wants to request from a website a page with url /pages/index.php. His browser prepares two requests forbthevserver and hashes the second request that it plans to send to the server later and saves the first two bytes of the hash result. Then the user's browser generates such ECDH key pair that the public one contains in any part of it the same two consecutive bytes as the hash's first two bytes by repeatedly recreating the key pairs. After that the public keys are negotiated with the remote server and the ECDH secret is calculated. And the second thing sent to the server is say an URL request (say get or post). As the server receives that request, it calculates the hash of the URL request it just received then gets the first two bytes of it and checks whether the public key which the server "thinks" belongs to the real user, actually contains those two consecutive hash bytes in it. The man in the middle attacker won't be able to prepare for the server such ECDH public key that would 100% contain that particular two byte sequence of the future request hash. Well, maybe not two bytes exactly, but one byte and say few bits to make calculations faster, it is even possible to set bit sequence in public keys instead of byte sequence and search for the sequence starting from any bit in the public key. And URL request is just a sample: of cause it can be any type of the second request the client plans to send to the server after establishing the encrypted link. We don't use the first request here to prevent the man in the middle from delaying server request until the first request is sent, as he could create proper keys after he gets the first request from the client.
I feel like these videos gloss over too many of the important issues with RSA - Padding and the need to use different keys for signing and encryption being the biggest ones. A video on Bleichenbacher's Oracle would be a good thing. Also RSA is very slow compared to EdDSA or even ECDSA. Since we're not directly encrypting messages and just using it for signing there's not much reason to use it outside of backwards compatibility with very old devices. If you're building a new system use Ed25519 or Ed448 via Libhydrogen or Libsodium.
I read somewhere long ago that not only was bulk encryption of data using RSA inefficient, but that there was issues with encrypting anything longer than the private key. I can't find where I read this, but could someone please explain this?
Can someone please explain how does a key exchange take place in case of DES / AES algorithm or in that matter any symmetric key algorithm? By the way excellent videos!!
If I already have a pre-shared public key of bob and know for sure that it belongs to the private key of bob. Is DH enough to authenticate the server? I think the key exchange will always fail to produce the same value when there is someone else pretending to be bob. Right?
I have a question ..... is 'g' same in both cases (Alice and Bob) or it can be different for both. How is 'g' and 'n' selected/shared before everything?
Question.....what would likely cause a Key exchange server password corruption? Is it likely to inexplicably fail without any type of human interface if it is encrypted?
I love how he puts so much effort into the diagrams, and then they just make a digital animation for each diagram anyway
RSA key exchange is fully susceptible by man in the middle as well. Sean has a private key and signs the data with its own key. Alice cannot know wether the data was encrypted and signed by Sean (man in the middle) or Bob since the real identity cannot be verified by an external authority. This is why we have certificates. SSL is what websites (HTTPS) are using to implement the whole chain of security features to finally become secure against man in the middle attacks.
The final step that SSL does ontop of RSA key exchange is to verify the public key with the certificate that server sent to the client upon SSL negotiation, using a global certificate store. In short, certificates themself have to be signed by a certificate authority, which (typically) can only be modified by Windows Updates (for Windows) and alike.
The certificates for HTTPS include the domain name in it's ServerName property to restrict the usage of the certificate to a particular website. The browser will make sure to verify this.
I think this should have been mentioned in the video before people run off and use RSA by itself when it really isn't secure against man in the middle (but it is secure against capturing of the data where it is not re-encrypted).
Side note, SSL includes all above mentioned features (configurable). If you're interested in playing around with this in programming, try out the OpenSSL library.
Also HTTPS is typically using an SSL library such as OpenSSL. For example, Chrome uses "boringssl" which is a library 'forked' from (based on) OpenSSL.
Really great comment, I salute you.
Thank you sir!
I think only diffie hellman is also secure against just capturing the data and not re-encrypting.
@YASH TRIVEDI Sorry for an extrodinarily late reply. I meant that RSA is secure against someone merely viewing the encrypted data. The RSA handshake has to be intercepted and new public/private key has to be generated in order to read (and potentially modify) the content. But this is what the certification process prevents.
Excellent Extension for this video thanks!
"Oh yes, I'm Bob!"
...
_But he isn't_
Top 10 Anime Plot twists
What a twist :O!
*KSP intensifies*
spoiler at 2:08
THEN WHO WAS PHONE
The man, the legend, Dr. Mike Pound!
hello andres, looking forward to our next computer science lesson
@@slopeydopey3108 sus
Please keep doing this!
cosa ci fai qua zombiebest hahahah
I love how the host is so attentive and asked the question at the end. I had the same while watching the video
Mike Pound is love. Mike Pound is life.
Mike Pounds the keyboard and your mom.
that thumbnail face tho
Came looking for this comment.
He's about to apply his Diffie Helmen key.
Not ashamed to say i saved it for future reference.
00:26 Caught it!
Emo Peter in his natural habitat
* waiting for the elliptic curve cryptography video impatiently *
* waiting for the Unbalanced Oil and Vinegar video impatiently *
Yes!!!
lattice cryptography video pls
Yes please do a video on ECDH
A video on PAKE would also be nice.
Mike is absolutely phenomenal! Rarely you see someone so knowledgeable and soooo funny at the same time. To use one of his words - "brilliant"!! :-)
I am taking network security class in college and this video explore a little more in depth of what I have learned so far. Very satisfied all the works from computerphile. :)
Forgot to mention the necessity of being able to safely share the public key, otherwise Sean could just nab that as well and do the same attack (why yes, I am Bob! You can verify that by checking me against the public key I just sent you!)
That's where things like certificate authorities come in -- a (hopefully) trusted third party that can retain Bob's public key for him such that he doesn't have to send it to Alice himself and therefore Sean has no chance to inject himself into the conversation.
Of course, that just punts the problem up a level: How can you trust that Bob's public key actually came from the CA? If Sean is operating at Alice's end of the connection, he could potentially intercept communication to the CA server as well as to Bob. As far as I know (and I might not be entirely accurate here..) this is resolved primarily by your OS and/or browser having a built-in list of trusted CAs (and we just assume that Sean hasn't been able to hack her browser or OS install.. if he had that level of access to Alice's machine, the whole question is moot anyway since he could just install a keylogger or whatever and capture the session directly.) So the CA send Bob's public key and authenticates themselves using their private key.. Alice can then use the CA's public key that she has stored locally to verify them, allowing her to safely retrieve Bob's public key and in turn use that to verify Bob.
But that means trusting the CA (in the social sense, rather than the computational sense.) There was one big one from China this past year.. maybe 2..? that Google removed from Chrome's trusted list and the other major browsers slowly followed suit, because the CA wasn't acting trustworthy and could have potentially compromised security by double-issuing certificates and back-dating expiry dates and things like that. For the most part though, that's not a huge problem since CAs are basically out of business when the browsers stop trusting them -- meaning they have a huge incentive to play by the rules and those that don't won't matter for long either way.
thank you for uploading and have a happy new year. cheerio Toni. PS: I really like all of your films, they are totally informative for me, cheers
Dr. Conspicuously Inconspicuous Smirk is back!
I’ve watched most of this stuff on encryption and I don’t fully understand it, but this chap is brilliant at explaining what is going on plus the pros/cons of each system. Engrossing.
Not only does RSA hope that your private key doesn't get leaked, it also needs to assume that only Bob can get an RSA key pair for his domain name. Anyways, great video guys!
I create RSA for staff001.vpn.client_company_name_or_any_other_domain_that_I_want. My VPN only trusts my own CA. Create any domain that you like; unless you compromise my CA you are not getting in. (I also my Customer CA signing keys automatically roll on a monthly basis.)
Reckless Roges Do you offer SRP certificates?
I didn't understand much of this, but I love listening to Dr. Pound.
Great video. Understanding these sort of key exchanges and realising how they can be broken by a Man in the Middle attack like this shows just what a huge security problem Superfish was (and probably still is on some computers). If you haven't seen it, look for the Computerphile video with Tom Scott from 2015 called "Man in the Middle Attacks & Superfish".
I have been wondering for a long time why we can't just encrypt the symmetric key with RSA and now i finally know the answer!!!!! Thank you :)
Clear explanation, I am master student at Turkey, security course lecturer doesn’t provide this explanatory. Thanks
The best part of this video is when the interviewer says, "Diffie Hellman is dead in the water" and Dr. Mike Pound(with the most hilarious expression says, "Diffie Hellman is in REAL TROUBLE HERE!" I couldn't stop laughing and laughing! Awesome video.
Funny British humor :)
OK, so...
We use RSA to verify your identity versus a database of public keys, in order use Diffie-Hellman to make a short-lived shared key, all to send a one-time private key for use with AES for the final communication.
I love it!
But then, how can we verify that the public key is actually Bobs public key? *Insert root certificate explanation here
Root certificates are a whole other can of worms...
There's a bunch of problems with it, but it gets kinda complex and I'm not a good person for explaining that...
The Certificate issuing authorities are the heart of the problem in any event.
totally agree. OP should just google "Honest Achmed" to get a explanation to the extend of this mess.
Well here's a basic explanation. TLS guarantees the authenticity, Alice will know the key is Bob's public key because Sean cannot sign a certificate tied to his key that will be acknowledged by a certificate authority.
NO! Not root certificate rubbish. Much more fun: Key signing parties! (Web of Trust.)
+Kuralthes +Safety
Certification Authorities, Root Certification Authorities and the Chain of Trust are not so much a mess, as much as they are simply *flawed* . Rather than rejecting the system outright because it doesn't perfectly defend against *every* conceivable attack, it should instead be a reminder that *NO* security mechanism is completely impervious to attacks -- especially not to attacks involving Human Error.
Finally, a computerphile video I actually understand, thanks to my knowledge with PGP
I discovered this channel a few days ago and I am already addicted to it... I have watched a dozen of your videos already and I liked each and every single one. All the computerphile team has a gift, I wish I could explain things the way you do.
One question came to my mind while watching this particular video though:
After having watched this video it is clear why, even with the server's public key, an extra "final" key is needed (the one that is going to be used to encrypt the requests and the requests and the responses before the transmission) using the DH key "exchange" (I used the quotes because in another video it is very well explained that this key is not really exchanged but generated at both sides equally instead). But the generation of this key has a computing cost at both sides, especially at the server side which needs to generate DH symmetric keys for all clients that are connected to it.
My question then is: wouldn't it be better that, instead of using DH, the client generated not a random symmetric key - not a good idea in case the server certificate's private key gets compromised, as it is explained in this video - but a random pair of private/public asymmetric keys and sent the public one to the server? (just keys, not certificates, no need to check any certification validity at this level), so the protocol would look something like
1) client -> hello -> server
2) server -> certificate with public key -> client
3) client - checks the certification's validity and, if valid, generates a random pair of private/public keys
4) client -> client's public key from step 3 encrypted with the server's public key from step 2 -> server
5) server -> confirmation message encrypted with the server's private key (authenticity layer) + client's public key (confidentiality layer) -> client
6) client - checks that the message from step 5 can be decrypted (this would confirm that its public key has really reached the server).
7) client -> data request, encrypted with client's private key in 1st place (authenticity) + server's public key (confidentiality) -> server
8) server -> requested data, encrypted with server's private key (auth.) and client's public one (conf.) -> client
The benefit I see in this approach is that the cost of generating "final" asymmetric keys, even though it is going to be probably higher than using the DH process (maybe even higher than twice - the sum of the server's and the client's costs in DH), relies completely on the clients and this would give some rest to the server, which is the one that suffers the most. In case these keys generation part would take "too long" for the client, the keys generation could start asynchronously at the same time that the hello message is sent at step 1, and step 4 would have to wait until the client's keys are completed; of course, only if the server's certificate has been verified... but even if the server's certificate is not valid, that pair of keys could still be used/recycled by the client in a different session/web (even with a different server), so their generation would not be a waste of computing power, and would make the process faster for that other session - this would need a thorough testing by the client's developer to make sure that a pair of random keys is not erroneously flagged as "still-usable" (once assigned to a session, they should NOT be used by another one).
Maybe this is all madness... but your videos made my imagination fly 😅
Holy moly Dr. Pound is amazingly charming! Especially so when discussing nefarious business! :D
Strictly speaking, it's not RSA that rescues it, but A's existing knowledge of B's public key. Otherwise, the network can step in and say "I''m the server you requested, and this is my public key," and you have gotten nowhere. Usually, it is some certificate authority that is built into the browser. But the point is there needs to be a public key that the man in the middle can't lie about.
@2:10 "He isn't"
That look though...XD
6:00 “Other nefarious people are available” 😂
This series of videos are the best explanations ever thank you so much
I’m starting with the man in the middle
I’m asking him to change his ways
And no message could have been any clearer
If you wanna make the world a better place
Take a look at yourself, and then make a change
This video sidesteps a very important problem. How do I know I have Bob’s public key? For example, when Alice asks for Bob’s key, Sean can intercept that and send his own key, masquerading as Bob. You only pushed the problem one step down the stairs.
Yeah, noticed that as well. Maybe there's a clever bit that we missed...
Thats where certification authorities come in (i think). Only they can provide them. Essentially, certificates are the public key.
Depends on the implementation.
* In case of the browser, there is a whole "SSL/TLS certificate" scheme, where the root cert you used to verify is already installed on your computer (by Google, Microsoft, Apple, or Mozilla).
* In case of SSH, you store the PK from first visit.
* In case of random apps, they either piggyback off the SSL/TLS certificate system, or just carry their own public key cert with them in the app for verification.
In the certification, the identification (among other things) is signed by the certfication authoritie, So alice will know she got Sean certificate and not Bobs
"Pushing the problem one step down the stairs" is what infosec is all about. The more stairs, the better.
lucid and succinct! nicely done!
we need a video on the Intel #Meltdown bug pronto
Eye opener. I was going to use ECDH. Thankfully now I know I should youe ECDH+RSA.
I'm just glad you people are thinking hard about this, whilst I do my on-line banking on faith alone (so far).
I paid £9000 to learn this
I think you paid 9000£ to get a job. I don't think I could get a job in security by saying "I watch RUclips videos", heh.
I paid OVER 9000 :OOOOOOO
+ervin zhou
Nah, it's EXACTLY NINETHOUSAND!!!!
Mike Pound > 9k pound
I paid £9000 to have Mike Pound teach me this at University of Nottingham... well worth it!
THANK YOU - this is the info I've been looking for everywhere!
1:25 Not calling the attacker Eve. Instant dislike, unfollow and uninstall.
Maybe Mallory instead, Eve is for eavesdroppers.
or Trudy for intruder :-P
Or Mal/Mel
No. Eve is always a _passive eavesdropper_ . The _malicious active attacker_ is Mallory.
Aaaah, the new pens are glorious. Thank you.
Meltdown and Spectre soon pls
I didn`t get it. What is preventing Sean from acting exactly like Bob in the second scheme?
¥δΣΩφ Sean does not have Bob's private key. We also assume that only Bob can get Bob's private key for the domain name he is hosting.
Yes, but couldn't he decrypt the message from Bob with Bob's public key, encrypt it with is own private key and intercept the message where Alice trys to get Bob's public key und send his own instead?
Ah I see what you mean now, this assumes of course that Sean cannot fake Bob's public key.
no, he'd need to have the private key to decrypt, he can't decrypt using the public key
* cue explanation of Certificate Authorities *
Shaun? What happened to Eve? :)
I thought he was called Mallory. Eve can only eavesdrop; she can't alter messages or create new ones.
Lately, Eve got real stealthy and now controls both endpoints.
Do the Spectre CPU flaw!
Thanks for spelling "Sean" correctly.
my professor actually linked this video in the homework and had us watch it and the homework had questions about it
Best. Thumbnail. Ever.
I'm glad Dr Pound listens to the 2 serving suggestion on the Pepsi haha
These explanation Videos are superb!
Now i have some hope, that i can get through my exams :D
the scenario he explains is when the bob and alice already trust each other (they communicated before and alice knows bobs public key), but what about when a connection is being established for the first time (bob has to give his public key to alice)? is man in middle possible still?
The actual problem with using RSA for encryption of large amounts of information, like webpages and files instead of just key hashes, is that the larger the amount of information, the longer the calculation takes, so it's not efficient. Assymmetric encryption algorithms can take up to 2000x longer than symmetric encryption to encrypt and decrypt
This is awesome. Best explanation ever
That is a genuinely terrifying thumbnail.
The digital signature doesn't stop the man-in-the-middle attack because the attacker can gain access to the public key for decryption. I mean both Alice and Bob can realize that their communication have been intercepted but if Bob in that scenario sends something important right from the very start, that's basically it
The public key is not to keep the message secret, it is only to show that Bob sent the message that says it came from Bob. Only he can sign the message with his private key, so any message that is de-signable with his public key definitely came from him. A man in the middle can learn what (g^a)%n and (g^b)%n are, but as we learned in the other videos, that isn't enough to decrypt the traffic
If there are no certificates involved (like SSH), this will only work if the first exchange is safe, right? From what I understood, if the first exchange is compromised then the following ones will be too. Can someone please give me some insight?
What's to stop Sean doing the same man-in the middle attack on the private/public keys? It would require an out-of-band secure communication for Alice and Bob to know the true public key of each other.
This video is really great. I'm glad I found it
The "He isn't." face
Nicely explained, thanks!
We need a video on speculative execution!
Mike Pound fan here, keep it up! :)
Thank you for answering my question!
This is beautiful.
i think it needs more details? because people will assume that as long as you are the man in the middle at the start! you can still decrypt and get all the messages and just pretend to be bob, you couldnt jump in half way through for sure with this explanation, but you forgot to mention that certificate authorities give pre installed keys to peoples computers so that the initial handshake doesnt get hijacked. that is explained in a previous video as i remember
Please talk about Post-Quantum Cryptography!
been wearing that same sweater in the last 3 videos bro!
Nothing wrong with having a video sweater.
How RSA is preventing from MITM? MITM is not only about changing a message but also about reading it. So in presented scenario Shaun can still reads what Bob is sending to Alice and vice versa, as Bob in only signing a message, not encrypting it.
Isn't Sean doing Malcolm's job?
I call it Mallory's job
I always thought it was Charlie to keep the letter scheme up
How does using RSA prevent Sean from spoofing Alice's request to get Bob's public key. Couldn't he not block that and send his own?
What a legend!
excellent video, are you going to do one on public key infrastructure to show how certificates are trusted, and how it ties into RSA?
One other problem that we would face if we only use RSA for sharing secret key would be that we would need public key of Alice (client) to encrypt the secret key. And in almost all the cases of web traffic, only servers have digital certificates, not the client.
Normally as a client you'd have access to your server's public key, and Alice will send her message encrypted with the server public key so only your server will be able to decryped it, and same on the way back.
When it comes to other services, you have a certificate authorities to verify the server Alice is talking to is really who it claims to be.
5:38 How did Alice knew what process had to be done with bg to get the same encrypted message which Bob made with his bg? Anyone help!
Awesome video!!! Thanks
Wait, what stops Sean from doing the exact same? He could generate his own public and private key pair and tell Alice that his public key is Bob's public key. Now Alyce will use Sean's public key for verification purposes!
For that, we have certificate providers. Usually all of our devices are preloaded with a certificate from a certificate provider (there's actually several preloaded). Ordinarily, Bob goes to the certificate provider and asks them to sign Bob's public key. When Bob sends the public key, Alice uses the certificate provider's public key to see if the public key that Bob sent is actually Bob. If not, then they know something's off. In this case, your browser would give a giant red warning.
As far as I understand
Server sends the G, N and G^random signed with servers private key and sends along with the server certificate to client, once the client verifies the authenticity using PKI and he will send his G^random and encrypts this using servers public key. Thus they will both arrive at the shared secret key using DH with RSA. These keys are ephemeral, i.e a new key pair is generated for every new session with the server.
Now, since the basics are done, the only thing left is to talk about the SSL and Certiciface Authories and the delegation chain, right?
Loved this video!
This breaks if Sean is making modification while Alice and Bob are exchanging public keys. Sean can listen to Alice sending her public key (AlicePub) to Bob and instead of letting that public key reach Bob, he can send his own public key (SeanPub1) to Bob. Now Bob will sign the message containing Bob's public key (BobPub) using what he falsely believes to be Alice's public key (SeanPub1) and try sending it to Alice. Sean, man in the middle, then can decrypt the message and send another public key (SeanPub2) to Alice. In this way Bob successfully deceived Alice and Bob about each other's public keys.
thank you very much the video is really helpful
1:25 He lied about his name too? It's TRUDY!
What happens if Sean uses the same man-in-the-middle attack to fake someone's public key?
Did you cover how the public key is distributed in the first place? How do we verify a public is not one just sent from Sean?
beautiful
I think there is an error in the animation. When Alice generate a key a, she debts out g^a, not g*a. And when bob send message back to Alice, bob debts out g^(ab) not g*a*b.
What do you think of this scheme: say a user wants to request from a website a page with url /pages/index.php. His browser prepares two requests forbthevserver and hashes the second request that it plans to send to the server later and saves the first two bytes of the hash result. Then the user's browser generates such ECDH key pair that the public one contains in any part of it the same two consecutive bytes as the hash's first two bytes by repeatedly recreating the key pairs. After that the public keys are negotiated with the remote server and the ECDH secret is calculated. And the second thing sent to the server is say an URL request (say get or post). As the server receives that request, it calculates the hash of the URL request it just received then gets the first two bytes of it and checks whether the public key which the server "thinks" belongs to the real user, actually contains those two consecutive hash bytes in it. The man in the middle attacker won't be able to prepare for the server such ECDH public key that would 100% contain that particular two byte sequence of the future request hash. Well, maybe not two bytes exactly, but one byte and say few bits to make calculations faster, it is even possible to set bit sequence in public keys instead of byte sequence and search for the sequence starting from any bit in the public key. And URL request is just a sample: of cause it can be any type of the second request the client plans to send to the server after establishing the encrypted link. We don't use the first request here to prevent the man in the middle from delaying server request until the first request is sent, as he could create proper keys after he gets the first request from the client.
Make a video about meltdown/spectre please!
I have computer science degrees but no one explained like him back then, but i see he stopped making videos 😒
I feel like these videos gloss over too many of the important issues with RSA - Padding and the need to use different keys for signing and encryption being the biggest ones. A video on Bleichenbacher's Oracle would be a good thing.
Also RSA is very slow compared to EdDSA or even ECDSA. Since we're not directly encrypting messages and just using it for signing there's not much reason to use it outside of backwards compatibility with very old devices. If you're building a new system use Ed25519 or Ed448 via Libhydrogen or Libsodium.
I was waiting him to talk about certificate authorities to authenticate the public key of bob.. the video ended and I'm still waiting 🤣🤣🤣
I read somewhere long ago that not only was bulk encryption of data using RSA inefficient, but that there was issues with encrypting anything longer than the private key. I can't find where I read this, but could someone please explain this?
How do you derive the asymmetric keys? More maths please!
Can someone please explain how does a key exchange take place in case of DES / AES algorithm or in that matter any symmetric key algorithm? By the way excellent videos!!
How and when did Alice get Bob's Public key, for verification?
Hi, i love ur videos :)
Could you do Kerberos including weaknesses?
If I already have a pre-shared public key of bob and know for sure that it belongs to the private key of bob. Is DH enough to authenticate the server? I think the key exchange will always fail to produce the same value when there is someone else pretending to be bob. Right?
thank you so much sir
Continue working with *Ronaldhacks_01 on ||G* he will always help you
I have a question ..... is 'g' same in both cases (Alice and Bob) or it can be different for both.
How is 'g' and 'n' selected/shared before everything?
Question.....what would likely cause a Key exchange server password corruption? Is it likely to inexplicably fail without any type of human interface if it is encrypted?