Diffie-Hellman Key Agreement Method
RFC 2631

Document Type RFC - Proposed Standard (June 1999; Errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2631 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                       E. Rescorla
Request for Comments: 2631                                    RTFM Inc.
Category: Standards Track                                     June 1999

                  Diffie-Hellman Key Agreement Method

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   This document standardizes one particular Diffie-Hellman variant,
   based on the ANSI X9.42 draft, developed by the ANSI X9F1 working
   group. Diffie-Hellman is a key agreement algorithm used by two
   parties to agree on a shared secret. An algorithm for converting the
   shared secret into an arbitrary amount of keying material is
   provided. The resulting keying material is used as a symmetric
   encryption key.  The Diffie-Hellman variant described requires the
   recipient to have a certificate, but the originator may have a static
   key pair (with the public key placed in a certificate) or an
   ephemeral key pair.

Table of Contents

   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . .   2
   1.1. Requirements Terminology  . . . . . . . . . . . . . . . .   2
   2. Overview Of Method  . . . . . . . . . . . . . . . . . . . .   2
   2.1. Key Agreement . . . . . . . . . . . . . . . . . . . . . .   2
   2.1.1. Generation of ZZ  . . . . . . . . . . . . . . . . . . .   3
   2.1.2. Generation of Keying Material . . . . . . . . . . . . .   3
   2.1.3. KEK Computation . . . . . . . . . . . . . . . . . . . .   4
   2.1.4. Keylengths for common algorithms  . . . . . . . . . . .   5
   2.1.5. Public Key Validation . . . . . . . . . . . . . . . . .   5
   2.1.6. Example 1 . . . . . . . . . . . . . . . . . . . . . . .   5
   2.1.7. Example 2 . . . . . . . . . . . . . . . . . . . . . . .   6
   2.2. Key and Parameter Requirements  . . . . . . . . . . . . .   7
   2.2.1. Group Parameter Generation  . . . . . . . . . . . . . .   7
   2.2.1.1. Generation of p, q  . . . . . . . . . . . . . . . . .   8

Rescorla                    Standards Track                     [Page 1]
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 [RFC2119].

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                     [Page 2]
RFC 2631          Diffie-Hellman Key Agreement Method          June 1999

2.1.1.  Generation of ZZ

Show full document text