# How to make sure the pre-agreed information safe for DH-Key Exchange

The definition of DH key exchange was given as the method let two authenticate each other & exchange the crypto key over an insecure channel.

DH-key-exchange was innovated to defence man-in-the-middle attack, because hackers can not pretend the one you want to communicate without correct share key? or hacker don't know the key generator that Alice and Bob pre-agreed?

From the wiki example, it said "Note that the starting color (yellow) is arbitrary, but is agreed on in advance by Alice and Bob."

But it doesn't explain how they two agreed that generator in advance. If that generator share between them was known by the 3rd person, this person actually can use that information to pretend any one of Alice & Bob, to communicate with the other one.

-

I believe that you misunderstand what DH is doing.

DH-key-exchange was innovated to defence man-in-the-middle attack, because hackers can not pretend the one you want to communicate without correct share key? or hacker don't know the key generator that Alice and Bob pre-agreed?

Well, no, defending against active attackers, that is, attackers who can modify messages, is the one thing that Diffie-Hellman doesn't claim to do.

Instead, what it strives to solve is "how can Alice and Bob communicate securely, even if Eve can listen to everything they say?"

But it doesn't explain how they two agreed that generator in advance.

That's actually a very simple question; it can be as simple as "Alice says 'lets use this particular value for $g$ and $p$', and Bob says 'ok'. An Eve listening in also learns the values of $g$ and $p$, however we don't care about that; we assume that Diffie-Hellman is secure against evesdroppers even if they know the public values $g$ and $p$.

So, you'll ask the obvious question:

If Diffie-Hellman is secure only from passive attackers, what prevents someone in the middle from pretending to be one of the parties?

Absolutely nothing, if you are using Diffie-Hellman and nothing else. That's why we also use some other authentication method with Diffie-Hellman. There are several possible mechanisms, such as if Alice and Bob share a common secret (that no third party knows), that can be used to generate a Message Authentication Code of DH part of the exchange; alternatively, they can exchange certificates, that allows them to sign those same parts.

-

The basic DH key exchange is unauthenticated. Authentication needs a different mechanism and has nothing to do with the key exchange.

Depending on the attacker model, authentication is not possible, and especially it is not save vs man in the middle (e.g. in the Dolev Yao model). The attacker can just initiate a key exchange with both Alice and Bob, and transform messages afterwards accordingly without either of them noticing; Bob and Alice don't share the same key, they both share a key with Mallory.

Using the color example: The generator is not secret in DH. The color yellow can be chosen in public. The hardness of DH is, that if Alice chooses blue, Bob chooses red, and the messages are yellow + blue and yellow + red you can not compute yellow+red+blue, because if you mix them you get yellow+blue+yellow+red (that's an additional yellow part). The fact that yellow was used as baseline does not have to be secret in any way.

-