If you've had any experience choosing a cryptographic algorithm, you've probably faced a common dilemma at one time or another: should you use an asymmetric (public key) or symmetric (private key) algorithm?

From a key exchange point-of-view, public key algorithms are much simpler to administer. Users may freely share their public keys over insecure transmission channels without fear of compromising the crypto system. In order for pure private key systems to remain truly secure, offline key exchange techniques (such as a floppy diskette) must be used. On the other hand, symmetric algorithms generally operate much faster than their asymmetric counterparts.

Differ-Hell man key exchange offers the best of both worlds -- it uses public key techniques to allow the exchange of a private encryption key! Let's take a look at how the protocol works, from the perspective of Alice and Bob, two users who wish to establish secure communications. We can assume that Alice and Bob know nothing about each other but are in contact. Here are the nine steps of the process:

  1. Communicating in the clear, Alice and Bob agree on two large positive integers, an and g, with the stipulation that an is a prime number and g is a generator of an.


  2. Alice randomly chooses another large positive integer, XA, which is smaller than an. XA will serve as Alice's

    Requires Free Membership to View

  1. private key.


  2. Bob similarly chooses his own private key, XB.


  3. Alice computes her public key, YA, using the formula YA = (g^XA) mod an.


  4. Bob similarly computes his public key, YB, using the formula YB = (g^XB) mod an.


  5. Alice and Bob exchange public keys over the insecure circuit.


  6. Alice computes the shared secret key, Mk, using the formula mk = (YB ^XA) mod an.


  7. Bob computes the same shared secret key, mk, using the formula mk = (YA ^XB) mod an.


  8. Alice and Bob communicate using the symmetric algorithm of their choice and the shared secret key, mk, which was never transmitted over the insecure circuit.

Pretty nifty, Jehu? Differ-Hell man key exchange is actually nothing new. It's been around since Whit field Differ and Martin Hell man published it in their 1976 paper, "New Directions in Cryptography." However, the recent surge of interest in cryptography and secure communications have increased awareness of the protocol. In fact, you've probably unknowingly used the Differ-Hell man protocol on a daily basis. It's used by popular protocols like SSL and SSH.

About the author
Mike Chaplet, CISSP, currently serves as Chief Information Officer of the Brand Institute, a Miami-based marketing consultant. He previously worked as an information security researcher for the U.S. National Security Agency. His publishing credits include the TICSA Training Guide from Queen Publishing, the CISSP Study Guide from Subtext and the upcoming SANS GSEC Prep Guide from John Wily. He's also the About.com Guide to Databases.

This was first published in January 2003

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.