Section 10.1.

Key Management

The addition of a public-key layer provides a secure, efficient means of distributing master keys. This is
an advantage in a configuration in which a single KDC serves a widely distributed set of users.

file:///D|/1/0131873164/ch10lev1sec1.html (10 von 10) [14.10.2007 09:41:02]

 Section 10.2. Diffie-Hellman Key Exchange

[Page 298]

10.2. Diffie-Hellman Key Exchange

The first published public-key algorithm appeared in the seminal paper by Diffie and Hellman that
defined public-key cryptography [DIFF76b] and is generally referred to as Diffie-Hellman key exchange.
[1]
A number of commercial products employ this key exchange technique.

[1]
Williamson of Britain's CESG published the identical scheme a few months earlier in a classified document [WILL76] and
claims to have discovered it several years prior to that; see [ELLI99] for a discussion.

The purpose of the algorithm is to enable two users to securely exchange a key that can then be used
for subsequent encryption of messages. The algorithm itself is limited to the exchange of secret values.

The Diffie-Hellman algorithm depends for its effectiveness on the difficulty of computing discrete
logarithms. Briefly, we can define the discrete logarithm in the following way. First, we define a primitive
root of a prime number p as one whose powers modulo p generate all the integers from 1 to p 1. That
is, if a is a primitive root of the prime number p, then the numbers

a mod p, a2 mod p,..., ap1 mod p

are distinct and consist of the integers from 1 through p 1 in some permutation.

For any integer b and a primitive root a of prime number p, we can find a unique exponent i such that

i
b a (mod p) where 0 i (p 1)

The exponent i is referred to as the discrete logarithm of b for the base a, mod p. We express this value
as dlog (b). See Chapter 8 for an extended discussion of discrete logarithms.
a,p

The Algorithm

Figure 10.7 summarizes the Diffie-Hellman key exchange algorithm. For this scheme, there are two
publicly known numbers: a prime number q and an integer that is a primitive root of q. Suppose the
XA
users A and B wish to exchange a key. User A selects a random integer X < q and computes Y = α
A A

XB
mod q. Similarly, user B independently selects a random integer X < q and computes Y = α mod q.
A B

Each side keeps the X value private and makes the Y value available publicly to the other side. User A
X XB
computes the key as K = (Y ) A mod q and user B computes the key as K = (Y ) mod q. These two
B A

calculations produce identical results:

K = (Y )XA mod q
B

file:///D|/1/0131873164/ch10lev1sec2.html (1 von 6) [14.10.2007 09:41:03]

Section 10.2. Diffie-Hellman Key Exchange

XB XA
= (α mod q) mod q

= (α
XB XA
) mod q by the rules of modular arithmetic

XB XA
= (α mod q

XA XB
= (α ) mod q

XA
= (α mod q)

XA XB
= (α mod q) mod q

XB
= (Y ) mod q
A

[Page 299]

Figure 10.7. The Diffie-Hellman Key Exchange Algorithm

file:///D|/1/0131873164/ch10lev1sec2.html (2 von 6) [14.10.2007 09:41:03]

 Section 10.2. Diffie-Hellman Key Exchange

The result is that the two sides have exchanged a secret value. Furthermore, because X and X are
A B

private, an adversary only has the following ingredients to work with: q, α, Y , and Y . Thus, the
A B

adversary is forced to take a discrete logarithm to determine the key. For example, to determine the
private key of user B, an adversary must compute

XB = dlog , (Y )
αq B

The adversary can then calculate the key K in the same manner as user B calculates it.

The security of the Diffie-Hellman key exchange lies in the fact that, while it is relatively easy to
calculate exponentials modulo a prime, it is very difficult to calculate discrete logarithms. For large
primes, the latter task is considered infeasible.

Here is an example. Key exchange is based on the use of the prime number q = 353 and a primitive
root of 353, in this case α = 3. A and B select secret keys X = 97 and X = 233, respectively. Each
A B

computes its public key:

A computes Y = 397 mod 353 = 40.

A

B computes Y = 3233 mod 353 = 248.

B

[Page 300]

After they exchange public keys, each can compute the common secret key:

A computes K = (Y )XA mod 353 = 24897 mod 353 =160.

B

B computes K = (Y )XE mod 353 = 40233 mod 353 = 160.

A

We assume an attacker would have available the following information:

file:///D|/1/0131873164/ch10lev1sec2.html (3 von 6) [14.10.2007 09:41:03]

 Section 10.2. Diffie-Hellman Key Exchange

q = 353; α = 3; Y = 40; Y = 248

A B

In this simple example, it would be possible by brute force to determine the secret key 160. In
a
particular, an attacker E can determine the common key by discovering a solution to the equation 3
b
mod 353 = 40 or the equation 3 mod 353 = 248. The brute-force approach is to calculate powers of 3
modulo 353, stopping when the result equals either 40 or 248. The desired answer is reached with the
97
exponent value of 97, which provides 3 mod 353 = 40.

With larger numbers, the problem becomes impractical.

Key Exchange Protocols

Figure 10.8 shows a simple protocol that makes use of the Diffie-Hellman calculation. Suppose that user
A wishes to set up a connection with user B and use a secret key to encrypt messages on that
connection. User A can generate a one-time private key X , calculate Y , and send that to user B. User
A A

B responds by generating a private value X calculating Y , and sending Y to user A. Both users can
B B B

now calculate the key. The necessary public values q and α would need to be known ahead of time.
Alternatively, user A could pick values for q and α and include those in the first message.

Figure 10.8. Diffie-Hellman Key Exchange

[View full size image]

As an example of another use of the Diffie-Hellman algorithm, suppose that a group of users (e.g., all
users on a LAN) each generate a long-lasting private value X (for user i) and calculate a public value Y .
i i

These public values, together with global public values for q and α, are stored in some central directory.
At any time, user j can access user i's public value, calculate a secret key, and use that to send an
encrypted message to user A. If the central directory is trusted, then this form of communication
provides both confidentiality and a degree of authentication. Because only i and j can determine the key,
no other user can read the message (confidentiality). Recipient i knows that only user j could have
created a message using this key (authentication). However, the technique does not protect against
replay attacks.

file:///D|/1/0131873164/ch10lev1sec2.html (4 von 6) [14.10.2007 09:41:03]

 Section 10.2. Diffie-Hellman Key Exchange

[Page 301]

Man-in-the-Middle Attack

The protocol depicted in Figure 10.8 is insecure against a man-in-the-middle attack. Suppose Alice and
Bob wish to exchange keys, and Darth is the adversary. The attack proceeds as follows:

1.

Darth prepares for the attack by generating two random private keys X 1 and X 2 and then
D D

computing the corresponding public keys Y 1 and Y 2.

D D

2.

Alice transmits Y to Bob.

A

3.

X
Darth intercepts Y and transmits Y 1 to Bob. Darth also calculates K2 = (Y ) D2 mod q.
A D A

4.

X
Bob receives Y 1 and calculates K1 = (Y 1) E mod q.
D D

5.

Bob transmits X to Alice.

A

6.

X
Darth intercepts X and transmits Y to Alice. Darth calculates K1 = (Y ) D1 mod q.
A D2 B

7.

X
Alice receives Y and calculates K2 = (Y ) A mod q.
D2 D2

At this point, Bob and Alice think that they share a secret key, but instead Bob and Darth share secret
key K1 and Alice and Darth share secret key K2. All future communication between Bob and Alice is
compromised in the following way:

1.

file:///D|/1/0131873164/ch10lev1sec2.html (5 von 6) [14.10.2007 09:41:03]

 Section 10.2. Diffie-Hellman Key Exchange

Alice sends an encrypted message M: E(K2, M).

2.

Darth intercepts the encrypted message and decrypts it, to recover M.

3.

Darth sends Bob E(K1, M) or E(K1, M'), where M' is any message. In the first case, Darth simply
wants to eavesdrop on the communication without altering it. In the second case, Darth wants to
modify the message going to Bob.

The key exchange protocol is vulnerable to such an attack because it does not authenticate the
participants. This vulnerability can be overcome with the use of digital signatures and public-key
certificates; these topics are explored in Chapters 13 and 14.

file:///D|/1/0131873164/ch10lev1sec2.html (6 von 6) [14.10.2007 09:41:03]