RFC 2631 (rfc2631) - Page 2 of 13

Diffie-Hellman Key Agreement Method

RFC 2631          Diffie-Hellman Key Agreement Method          June 1999


   2.2.1.2. Generation of g . . . . . . . . . . . . . . . . . . .   9
   2.2.2. Group Parameter Validation  . . . . . . . . . . . . . .   9
   2.3. Ephemeral-Static Mode . . . . . . . . . . . . . . . . . .  10
   2.4. Static-Static Mode  . . . . . . . . . . . . . . . . . . .  10
   2.4. Acknowledgements  . . . . . . . . . . . . . . . . . . . .  10
   2.4. References  . . . . . . . . . . . . . . . . . . . . . . .  11
   Security Considerations  . . . . . . . . . . . . . . . . . . .  12
   Author's Address . . . . . . . . . . . . . . . . . . . . . . .  12
   Full Copyright Statement . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   In [DH76] Diffie and Hellman describe a means for two parties to
   agree upon a shared secret in such a way that the secret will be
   unavailable to eavesdroppers. This secret may then be converted into
   cryptographic keying material for other (symmetric) algorithms.  A
   large number of minor variants of this process exist. This document
   describes one such variant, based on the ANSI X9.42 specification.

1.1.  Requirements Terminology

   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
   "MAY" that appear in this document are to be interpreted as described
   in [RFC 2119].

2.  Overview Of Method

   Diffie-Hellman key agreement requires that both the sender and
   recipient of a message have key pairs. By combining one's private key
   and the other party's public key, both parties can compute the same
   shared secret number. This number can then be converted into
   cryptographic keying material.  That keying material is typically
   used as a key-encryption key (KEK) to encrypt (wrap) a content-
   encryption key (CEK) which is in turn used to encrypt the message
   data.

2.1.  Key Agreement

   The first stage of the key agreement process is to compute a shared
   secret number, called ZZ.  When the same originator and recipient
   public/private key pairs are used, the same ZZ value will result.
   The ZZ value is then converted into a shared symmetric cryptographic
   key. When the originator employs a static private/public key pair,
   the introduction of a public random value ensures that the resulting
   symmetric key will be different for each key agreement.






Rescorla                    Standards Track