Right, this simple model is vulnerable. They are actually having a conversation in the comments about this.
I just liked the way of explaining it to laypeople. Leaving all mathematics behind, taking a model that everyone understands (and yes, some commentators are missing the point, discussing how it is possible to un-mix colors).
Eh, I feel like if you can concisely highlight a metaphor's shortcomings it only makes for a stronger, less ambiguous, metaphor.
For example, it hadn't explicitly occurred to me that it would be easier to separate the colors than it would the numbers. Before reading these comments I was assuming that the factor I was missing had to do with separating the numbers becoming exponentially harder of a problem as the numbers grew larger. Reading about the discussion of this metaphor in the comments helped me realize that I was missing a deeper and essential part of this puzzle that I've been yearning to understand concretely for years.
Totally agree that the metaphor is an excellent start for the layperson.
All key exchanges are vulnerable to an active MITM attack, whether using pigments or some cryptographic key exchange.
The only way around it? Some other method of verifying the key, which isn't vulnerable to a MITM, like meeting in person, or using Certificate Authorities.
We did one last semester at my school's cybersecurity club. I don't really know much about cybersecurity, just a hobbyist, but I had a fun time nerding out and giving freshmen a tough time with their drivers licenses.
Or using SAS [1] and PGP check words [2] ala implementations like ZRTP [1]
edit: I realize the salient point is that this gives you assurance that the encryption handshake hasn't be intercepted but no guarantee as to the identity of the person you've connected to. With real-time VoIP this potentially isn't a problem (yet) as it's relatively obvious who you're chatting to on the phone.
the common color can be public, there is no point in manipulating it. Anybody manipulating it will not be using the common color any more.
if you are saying that you plan to trust the MITM to give you the common color, then it's not a common color, it's not something you have in common with the party you wish to perform a key exchange with.
or to put it another way, notice that the protocol does not start out with "exchange a common color"
If you check the cryptographic explanation, you see the first step is sending p and g to the other party. This is the 'common color' you talk about. These aren't predefined in the protocol.
my explanation was correct, "common" (but not secret) means that both parties have it (each party also has a secret) and that is the key element to understand what is good about the protocol and what problems it solves. By seeming to correct me, you are actually confusing the people I just explained it to. You can if you wish go ahead and explain what limitations this puts on the protocol, but try to help people understand rather than just throwing confetti in the air.
I wonder if there's a similar way to show how you would encrypt and then decrypt a message using ElGamal, which is the natural evolution of Diffie-Hellman.
Thanks. I think we'll change the url to this from [1].
Hacker News is an English-language site. Obviously, content in other languages is often just as good or better. But it is what this site is. Machine translation is surprisingly not bad these days, but I don't think it's a general solution here.