Key Exchange Problems - Computerphile

"Oh yes, I'm Bob!" ... But he isn't

I love how he puts so much effort into the diagrams, and then they just make a digital animation for each diagram anyway

The man, the legend, Dr. Mike Pound!

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.

Please keep doing this!

that thumbnail face tho

I love how the host is so attentive and asked the question at the end. I had the same while watching the video

* waiting for the elliptic curve cryptography video impatiently *

Mike Pound is love. Mike Pound is life.

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.

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

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. :)

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 😅

Mike is absolutely phenomenal! Rarely you see someone so knowledgeable and soooo funny at the same time. To use one of his words - "brilliant"!! :-)

This series of videos are the best explanations ever thank you so much

6:00 “Other nefarious people are available” 😂

@2:10 "He isn't" That look though...XD

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.

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".