Secure Key Exchange over an Insecure Medium with Public Key Cryptography - Implementing SSL/TLS Using Cryptography and PKI - page 131

And the client computes

(g b %p)
The server transmits Ys to the client and the client transmits Yc to the server.
At this point, they each have enough to compute the fi nal value Z

Yc

g ab % p :

Client Server
(g a %p) b %p (g b %p) a %p
(Ys) b %p (Yc) a %p
Z Z

And Z is the key that both sides use as the symmetric key. The server knows
the value a (because it chose it), and the client knows the value b (because,
again, it chose it). Neither knows the other's value, but they don't need to. Nor
can an eavesdropper glean the value of Z without either a or b , neither of which
has been shared. You can think of each side as computing one-half of an expo-
nentiation and sharing that half with the other side, which then completes the
exponentiation. Because the exponentiation operation is done mod p , it can't
be feasibly inverted by an attacker, unless the attacker has solved the discrete
logarithm problem.
Using the mod_pow function developed earlier for RSA, this is simple to imple-
ment in code as shown in Listing 3-26.

Listing 3-26: “dh.c” Diffe-Hellman key agreement

static void dh_agree( huge *p, huge *g, huge *e, huge *Y )
{
mod_pow( g, &e, p, Y );
}

static void dh_finalize( huge *p, huge *Y, huge *e, huge *Z )
{
mod_pow( Y, &e, p, &Z );
}

In fact, there's not much point in defi ning new functions to implement this
because all they do is call mod_pow . Given p , g , and a , the server does something like
huge Ys, Yc, Z;
dh_agree( p, g, a, &Ys );
send_to_client( &Ys );
receive_from_client( &Yc );
dh_finalize( p, Yc, a, Z );
// ... use “Z” as shared key

At the same time, the client does:
huge Ys, Yc, Z;
dh_agree( p, g, b, &Yc );