Key Exchange Problems - Computerphile

Diffie Hellman has a flaw. Dr Mike Pound explains how a man in the middle could be a big problem, unless we factor it in...

Elliptic Curve Cryptography: Coming Soon!

This video was filmed and edited by Sean Riley.

[NovemberBegin]

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

[funkynicco]

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.

[hiperalee]

"Oh yes, I'm Bob!"

...

_But he isn't_

[daft_punker]

The man, the legend, Dr. Mike Pound!

[chinmayrath]

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

[Ribby]

Mike Pound is love. Mike Pound is life.

[klwtherd]

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.

[Michael-vsmw]

* waiting for the elliptic curve cryptography video impatiently *

[andreicoco]

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

[Anvilshock]

Dr. Conspicuously Inconspicuous Smirk is back!

[vjstgdi]

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

[toniturnwald]

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

[altrag]

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.

[AustinHarsh]

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!

[richardslater]

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.

[PvblivsAelivs]

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.

[UntouchedWagons]

I didn't understand much of this, but I love listening to Dr. Pound.

[debroy]

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

[tomihawk]

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

[uhdfxbl]

6:00 “Other nefarious people are available” 😂