Diffie-Hellman Session Key Exchange
Hewlett-Packard Company Virtual Private Networking Concepts Guide
2-11
Diffie-Hellman Session Key Exchange
Diffie-Hellman Session Key Exchange
Diffie-Hellman Session Key Exchange
Diffie-Hellman Session Key Exchange
The Diffie-Hellman key exchange protocol is based on an
asymmetric algorithm. In asymmetric cryptographic systems,
the key used to encrypt data is different from the key used to
decrypt it. The key used to encrypt the data is usually referred to
as a public key, while the key used to decrypt the data is called
the private key, and the public key is derived from the private
key. The length of the public and private keys can be 512 bits,
1024 bits, or 2048 bits.
The problem of key exchange between VPN devices is solved
using a protocol known as the Diffie-Hellman key exchange
protocol. This protocol must be followed whenever two VPN
devices first begin to communicate, or when a session key
expires. The strength of this protocol is that it allows the two
devices to negotiate or decide on a common session key without
ever exchanging the key.
In general, when two devices exchange some data using an
asymmetric cryptographic system, each device first requests the
public key of the other device. They then use the public key of
the other device to encrypt the data. When the other device
receives the data, it can then use its private key to decrypt the
data. As the name suggests, public keys are not secret and are
made known to any device that requests them. Private keys,
however, should never be revealed or distributed.
The Diffie-Hellman protocol specifies that the two devices
negotiating a common session key should each select half of a
session key. They must also each derive some parameters that
can be used to calculate the same half-session key. It is these
parameters that are exchanged using the public/private key
technique. Once the parameters are exchanged, then the second
half of the session key can be calculated.
Notice that the session keys are never actually exchanged. The
parameters for calculating half a session key are sent. To derive
the full session key, both packets must be trapped and then
broken. The effort required to break keys with lengths of 512,
1024, or 2048 bits makes this attack impractical.
The vulnerability of this type of key exchange protocol is the
public key exchange.
