Diffie-Hellman Key Exchange
Art of the Problem9 HN recommenders · 2016–2024
938K views · explainer · evergreen · Uploaded 2012-07-31
A short explainer on the history and mechanics of public key cryptography and the Diffie-Hellman key exchange. It uses a mixing-paint-colors analogy to show how two parties can agree on a shared secret in public.
It is the go-to beginner explanation of Diffie-Hellman, recommended because the paint analogy makes the idea click without prior cryptography knowledge.
51:32Behind the Scenes of iOS Security
Black Hat
12:01Why Electronic Voting Is Still A Bad Idea
Tom Scott
25:16But how does bitcoin actually work?
3Blue1Brown
48:02BlackHat USA 2011: SSL And The Future Of Authenticity
Christiaan008
14:34Blockchains Are a Bad Idea (James Mickens)
HBS Digital Initiative
2:18:23Line Goes Up – The Problem With NFTs
Folding Ideas
1:32:08Theory and Practice of Cryptography
Google TechTalks
8:21Why Electronic Voting is a BAD Idea - Computerphile
Computerphile
11 comments from Hacker News
This is a great pair of videos that intuitively explain Diffie-Helman key exchange and then the RSA algorithm in a way that requires no previous knowledge of cryptography: "Public key cryptography - Diffie-Hellman Key Exchange" [VIDEO] "Public Key Cryptography: RSA Encryption Algorithm" [LINK] Good coverage of the fundamentals before attempting a deeper understanding of PGP specifically.
For idiots like myself, I found this video, Public key cryptography - Diffie-Hellman Key Exchange (full version), to be completely enlightening using mixed colors to explain the most basic features of a cryptography algorithm.[0] [0] [VIDEO]
I recommend beginning at the fundamentals. For example here's a video that walks through Diffie Hellman, so that anybody can follow, you can probably sprint through it, but by taking it slow they avoid accidentally forgetting anything important. [VIDEO] Grasping the fundamentals means that when it comes to policy decisions (e.g. in the management of certificates) you can see what the consequences of a particular decision are, rather than just hoping that whoever proposed that policy knew what they were doing. For example, I think a lot of people today use Certificate Signing Request (CSR) files without understanding them at all. But once you have a grounding in the underlying elements you can see at once what the CSR does, and why it's necessary without needing to have that spelled out separately. Or another example, understanding what was and was not risky as a result of the known weakness of SHA-1. I saw a lot of scare-mongering by security people who saw the SHA-1 weakness as somehow meaning impossible things were now likely, but it only affected an important but quite narrow type of usage, people who understood that could make better, more careful decisions without putting anybody at risk.
As others have already pointed out, this explanation focuses on the RSA key exchange, which has been deprecated. It's not recommended for use with the current line of protocols (TLS 1.2 and earlier) and it's been completely removed from TLS 1.3 (work in progress, but close to being finished). The key weakness of the RSA key exchange is that session encryption keys are transported over the network encrypted with the server's public key. When the server's private key is compromised in some way, the attacker can passively decrypt all traffic, they can also "go back in time" to decrypt all previous conversations they might have recorded and kept. For a more secure handshake approach, consider the Diffie-Hellman key exchange, which is a way for two parties to agree on a secret number (a very large number when used for encryption, of course) that third party can't discover from looking at the network traffic. It's a very simple and intuitive algorithm; there's a great video that explains it here: [VIDEO] Today, we generally use the ephemeral elliptic curve DH variant (ECDHE), which has better security characteristics and works much faster. However, DH is not sufficient, you must also authenticate the other party. Otherwise you could be negotiating your key exchange with the attacker and not the real recipient. This is where public cryptography comes in. After the key exchange, both parties use their private keys to sign the transcripts of the entire conversation up until that point
If you haven't seen it, there's a pretty neat video that outlines how public-key cryptography works using paint colors [1]. It's focused on Diffie-Hellman key exchange, but it's a great intro for beginners to be able to visualize the concepts, and I think helps provide some context before jumping right into the GPG command line. [1] [VIDEO]
Interesting explanation - thanks for sharing. I find it easier to visualise, through colours of paint, for a high-level metaphor of the DH key exchange process, which may be useful - [VIDEO]
Interesting, thanks for sharing (I too was curious). This is my favorite video on Diffie-Hellman key exchange which is a slightly different problem (sharing a secret, without the constraint of dividing the key): [VIDEO] (oh, hey, same channel! Guess I'll need to check out more videos from here!)
Here is another video from "Art of the Problem" that uses the same analogy that really helped me understand this better: [VIDEO]
When reading the title, this came to mind: [VIDEO] (Diffie-Hellman key exchange explained using paint). There is also this one by Computerphile: [LINK]
This is the only video that ever explained it concisely and clearly, IF you don't care about trying to actually implement it: [VIDEO]
Reminds me of a video[0] that describes Diffie-Hellman key exchange in terms of mixing color values (as globs of oil paint). I guess in this game you're guessing the mix of primary colors, so maybe it doesn't hold the same property of difficulty in deriving the constituents? [0] [VIDEO]