NIST Special Publication 800-56A
Revision 3

Recommendation for Pair-Wise
Key-Establishment Schemes Using
Discrete Logarithm Cryptography

Elaine Barker
Lily Chen
Allen Roginsky
Apostol Vassilev
Richard DavisThis publication is available free of charge from:https://doi.org/10.6028/NIST.SP.800-56Ar3

C O M P U T E R

S E C U R I T Y

NIST Special Publication 800-56A
Revision 3

Recommendation for Pair-Wise KeyEstablishment Schemes Using Discrete
Logarithm Cryptography
Elaine Barker
Lily Chen
Allen Roginsky
Apostol Vassilev
Computer Security Division
Information Technology Laboratory
Richard Davis
National Security Agency
This publication is available free of charge from:https://doi.org/10.6028/NIST.SP.800-56Ar3
April 2018

U.S. Department of Commerce
Wilbur L. Ross, Jr., Secretary
National Institute of Standards and Technology
Walter Copan, NIST Director and Under Secretary of Commerce for Standards and Technology

NIST SP 800-56A REV. 3

RECOMMENDATION FOR PAIR-WISE KEY ESTABLISHMENT
USING DISCRETE LOGARITHM CRYPTOGRAPHY

Authority
This publication has been developed by the National Institute of Standards and Technology (NIST) in
accordance with its statutory responsibilities under the Federal Information Security Modernization Act(FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing
information security standards and guidelines, including minimum requirements for federal information
systems, but such standards and guidelines shall not apply to national security systems without the express
approval of appropriate federal officials exercising policy authority over such systems. This guideline isconsistent with the requirements of the Office of Management and Budget (OMB) Circular A-130.
Nothing in this publication should be taken to contradict the standards and guidelines made mandatory andbinding on federal agencies by the Secretary of Commerce under statutory authority. Nor should theseguidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce,
Director of the OMB, or any other federal official. This publication may be used by nongovernmentalorganizations on a voluntary basis and is not subject to copyright in the United States. Attribution would,
however, be appreciated by NIST.
National Institute of Standards and Technology Special Publication 800-56A Revision 3
Natl. Inst. Stand. Technol. Spec. Publ. 800-56A Rev. 3, 151 pages (April 2018)
CODEN: NSPUE2This publication is available free of charge from:https://doi.org/10.6028/NIST.SP.800-56Ar3
Certain commercial entities, equipment, or materials may be identified in this document in order to describe an
experimental procedure or concept adequately. Such identification is not intended to imply recommendation or
endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best
available for the purpose.
There may be references in this publication to other publications currently under development by NIST in accordancewith its assigned statutory responsibilities. The information in this publication, including concepts and methodologies,
may be used by federal agencies even before the completion of such companion publications. Thus, until eachpublication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For
planning and transition purposes, federal agencies may wish to closely follow the development of these new
publications by NIST.
Organizations are encouraged to review all draft publications during public comment periods and provide feedback to
NIST. Many NIST cybersecurity publications, other than the ones noted above, are available athttps://csrc.nist.gov/publications.

Comments on this publication may be submitted to:
National Institute of Standards and Technology
Attn: Computer Security Division, Information Technology Laboratory
100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930
Email: SP800-56a_comments@nist.gov
All comments are subject to release under the Freedom of Information Act (FOIA).

iNIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

Reports on Computer Systems Technology
The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology(NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s
measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept
implementations, and technical analyses to advance the development and productive use of information
technology. ITL’s responsibilities include the development of management, administrative, technical, andphysical standards and guidelines for the cost-effective security and privacy of other than national securityrelated information in Federal information systems. The Special Publication 800-series reports on ITL’s
research, guidelines, and outreach efforts in information system security, and its collaborative activities
with industry, government, and academic organizations.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Abstract
This Recommendation specifies key-establishment schemes based on the discrete logarithm
problem over finite fields and elliptic curves, including several variations of Diffie-Hellman and
Menezes-Qu-Vanstone (MQV) key establishment schemes.
Keywords
Diffie-Hellman; elliptic curve cryptography; finite field cryptography; key agreement; key
confirmation; key derivation; key establishment; MQV.
Acknowledgements
The authors gratefully acknowledge the contributions on previous versions of this document by
Mike Hopper, Don Johnson, Sharon Keller, Laurie Law, and Miles Smid.
Conformance Testing
Conformance testing for implementations of this Recommendation will be conducted within theframework of the Cryptographic Algorithm Validation Program (CAVP) and the Cryptographic
Module Validation Program (CMVP). The requirements of this Recommendation are indicated by
the word “shall.” Some of these requirements may be out-of-scope for CAVP or CMVP validation
testing, and thus are the responsibility of entities using, implementing, installing or configuring
applications that incorporate this Recommendation.

ii

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

Table of Contents
1. Introduction .............................................................................................................. 1
2. Scope and Purpose ................................................................................................. 1
3. Definitions, Symbols and Abbreviations ............................................................... 2
3.1

Definitions........................................................................................................................ 2

3.2

Symbols and Abbreviations ............................................................................................. 9This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

4. Overview of Key-Establishment Schemes ........................................................... 14
4.1

Key Establishment Preparations .................................................................................... 15

4.2

Key-Agreement Process................................................................................................. 17

4.3

DLC-based Key-Transport Process ............................................................................... 19

5. Cryptographic Elements ....................................................................................... 20
5.1

Cryptographic Hash Functions ...................................................................................... 20

5.2

Message Authentication Code (MAC) Algorithm ......................................................... 20
5.2.1

MAC Tag Computation for Key Confirmation ................................................. 20

5.2.2

MAC Tag Verification for Key Confirmation ................................................... 21

5.3

Random Number Generation ......................................................................................... 21

5.4

Nonce ............................................................................................................................ 21

5.5

Domain Parameters ........................................................................................................ 23
5.5.1

5.6

Domain-Parameter Selection/Generation .......................................................... 23
5.5.1.1

FFC Domain Parameter Selection/Generation.................................... 23

5.5.1.2

ECC Domain-Parameter Selection ..................................................... 24

5.5.2

Assurances of Domain-Parameter Validity ....................................................... 26

5.5.3

Domain Parameter Management........................................................................ 26

Key-Establishment Key Pairs ........................................................................................ 27
5.6.1

Key-Pair Generation .......................................................................................... 27
5.6.1.1

FFC Key-Pair Generation ................................................................... 27
5.6.1.1.1 Using the Approved Safe-Prime Groups ............................. 27
5.6.1.1.2 Using the FIPS 186-Type FFC Parameter-size Sets ............ 27iii

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

5.6.1.1.3 Key-Pair Generation Using Extra Random Bits .................. 27
5.6.1.1.4 Key-Pair Generation by Testing Candidates........................ 29
5.6.1.2

ECC Key-Pair Generation................................................................... 30
5.6.1.2.1 Key Pair Generation Using Extra Random Bits .................. 30
5.6.1.2.2 Key Pair Generation by Testing Candidates ........................ 31

5.6.2

Required Assurances .......................................................................................... 32
5.6.2.1

Assurances Required by the Key Pair Owner ..................................... 33

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

5.6.2.1.1 Owner Assurance of Correct Generation ............................. 35
5.6.2.1.2 Owner Assurance of Private-Key Validity .......................... 35
5.6.2.1.3 Owner Assurance of Public-Key Validity ........................... 36
5.6.2.1.4 Owner Assurance of Pair-wise Consistency ........................ 36
5.6.2.1.5 Owner Assurance of Possession of the Private Key ............ 37
5.6.2.2

Assurances Required by a Public Key Recipient ................................ 37
5.6.2.2.1 Recipient Assurance of Static Public-Key Validity ............. 39
5.6.2.2.2 Recipient Assurance of Ephemeral Public-Key Validity..... 39
5.6.2.2.3 Recipient Assurance of the Owner’s Possession of a Static
Private Key........................................................................... 40
5.6.2.2.4 Recipient Assurance of the Owner’s Possession of an
Ephemeral Private Key ........................................................ 42

5.6.2.3

Public Key Validation Routines.......................................................... 43
5.6.2.3.1 FFC Full Public-Key Validation Routine ............................ 43
5.6.2.3.2 FFC Partial Public-Key Validation Routine ........................ 44
5.6.2.3.3 ECC Full Public-Key Validation Routine............................ 44
5.6.2.3.4 ECC Partial Public-Key Validation Routine........................ 45

5.6.3

5.7

Key Pair Management........................................................................................ 46
5.6.3.1

Common Requirements on Static and Ephemeral Key Pairs.............. 46

5.6.3.2

Specific Requirements on Static Key Pairs ........................................ 46

5.6.3.3

Specific Requirements on Ephemeral Key Pairs ................................ 47

DLC Primitives .............................................................................................................. 48
5.7.1

Diffie-Hellman Primitives ................................................................................. 48
iv

NIST SP 800-56A Rev. 3

5.7.2

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

5.7.1.1

Finite Field Cryptography Diffie-Hellman (FFC DH) Primitive ........ 48

5.7.1.2

Elliptic Curve Cryptography Cofactor Diffie-Hellman (ECC CDH)
Primitive.............................................................................................. 49

MQV Primitives ................................................................................................. 50
5.7.2.1

Finite Field Cryptography MQV (FFC MQV) Primitive ................... 50
5.7.2.1.1 MQV2 Form of the FFC MQV Primitive ............................ 51
5.7.2.1.2 MQV1 Form of the FFC MQV Primitive ............................ 51

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

5.7.2.2

ECC MQV Associate Value Function ................................................ 51

5.7.2.3

Elliptic Curve Cryptography MQV (ECC MQV) Primitive ............... 52
5.7.2.3.1 Full MQV Form of the ECC MQV Primitive ...................... 52
5.7.2.3.2 One-Pass Form of the ECC MQV Primitive........................ 53

5.8

Key-Derivation Methods for Key-Agreement Schemes ................................................ 53
5.8.1

Performing the Key Derivation .......................................................................... 53

5.8.2

FixedInfo ............................................................................................................ 54
5.8.2.1

One-step Key Derivation .................................................................... 55
5.8.2.1.1 The Concatenation Format for FixedInfo ............................ 56
5.8.2.1.2 The ASN.1 Format for FixedInfo ........................................ 57

5.8.2.2

Two-step Key-Derivation (Extraction-then-Expansion)..................... 57

5.8.2.3

Other Formats for FixedInfo ............................................................... 57

5.9 Key Confirmation ........................................................................................................... 58
5.9.1

Unilateral Key Confirmation for Key-Agreement Schemes .............................. 58

5.9.2

Bilateral Key Confirmation for Key-Agreement Schemes ................................ 61

5.9.3

Selecting the MAC and Other Key-Confirmation Parameters .......................... 62

6. Key Agreement Schemes ...................................................................................... 64
6.1

Schemes Using Two Ephemeral Key Pairs, C(2e) ........................................................ 66
6.1.1

C(2e, 2s) Schemes .............................................................................................. 67
6.1.1.1

dhHybrid1, C(2e, 2s, FFC DH) Scheme ............................................. 68

6.1.1.2(Cofactor) Full Unified Model, C(2e, 2s, ECC CDH) Scheme .......... 70

6.1.1.3

MQV2, C(2e, 2s, FFC MQV) Scheme ............................................... 71v

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

6.1.1.4

Full MQV, C(2e, 2s, ECC MQV) Scheme ......................................... 73

6.1.1.5

Incorporating Key Confirmation into a C(2e, 2s) Scheme ................. 74
6.1.1.5.1 C(2e, 2s) Scheme with Unilateral Key Confirmation
Provided by Party U to Party V ........................................... 75
6.1.1.5.2 C(2e, 2s) Scheme with Unilateral Key Confirmation
Provided by Party V to Party U ........................................... 76
6.1.1.5.3 C(2e, 2s) Scheme with Bilateral Key Confirmation ............ 77

6.1.2
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

6.2

C(2e, 0s) Schemes .............................................................................................. 78
6.1.2.1

dhEphem, C(2e, 0s, FFC DH) Scheme ............................................... 79

6.1.2.2(Cofactor) Ephemeral Unified Model, C(2e, 0s, ECC CDH) Scheme 80

6.1.2.3

Key Confirmation for C(2e, 0s) Schemes ........................................... 81

Schemes Using One Ephemeral Key Pair, C(1e) Schemes ........................................... 82
6.2.1

C(1e, 2s) Schemes .............................................................................................. 82
6.2.1.1

dhHybridOneFlow, C(1e, 2s, FFC DH) Scheme ................................ 83

6.2.1.2(Cofactor) One-Pass Unified Model, C(1e, 2s, ECC CDH) Scheme.. 85

6.2.1.3

MQV1, C(1e, 2s, FFC MQV) Scheme ............................................... 88

6.2.1.4

One-Pass MQV, C(1e, 2s, ECC MQV) Scheme ................................. 90

6.2.1.5

Incorporating Key Confirmation into a C(1e, 2s) Scheme ................. 92
6.2.1.5.1 C(1e, 2s) Scheme with Unilateral Key Confirmation
Provided by Party U to Party V ........................................... 92
6.2.1.5.2 C(1e, 2s) Scheme with Unilateral Key Confirmation
Provided by Party V to Party U ........................................... 94
6.2.1.5.3 C(1e, 2s) Scheme with Bilateral Key Confirmation ............ 95

6.2.2

C(1e, 1s) Schemes .............................................................................................. 96
6.2.2.1

dhOneFlow, C(1e, 1s, FFC DH) Scheme ........................................... 97

6.2.2.2(Cofactor) One-Pass Diffie-Hellman, C(1e, 1s, ECC CDH) Scheme. 99

6.2.2.3

Incorporating Key Confirmation into a C(1e, 1s) Scheme ............... 101
6.2.2.3.1 C(1e, 1s) Scheme with Unilateral Key Confirmation
Provided by Party V to Party U ......................................... 101

6.3

C(0e, 2s) Schemes ........................................................................................................ 102
6.3.1

dhStatic, C(0e, 2s, FFC DH) Scheme .............................................................. 104
vi

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

6.3.2(Cofactor) Static Unified Model, C(0e, 2s, ECC CDH) Scheme..................... 105

6.3.3

Incorporating Key Confirmation into a C(0e, 2s) Scheme .............................. 107
6.3.3.1C(0e, 2s) Scheme with Unilateral Key Confirmation Provided by Party
U to Party V ...................................................................................... 107

6.3.3.2C(0e, 2s) Scheme with Unilateral Key Confirmation Provided by Party
V to Party U ...................................................................................... 109

6.3.3.3C(0e, 2s) Scheme with Bilateral Key Confirmation ......................... 110

7. Rationale for Selecting a Specific Scheme ........................................................ 112
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

7.1 Rationale for Choosing a C(2e, 2s) Scheme ................................................................... 113
7.2 Rationale for Choosing a C(2e, 0s) Scheme ................................................................... 114
7.3 Rationale for Choosing a C(1e, 2s) Scheme ................................................................... 115
7.4 Rationale for Choosing a C(1e, 1s) Scheme ................................................................... 116
7.5 Rationale for Choosing a C(0e, 2s) Scheme ................................................................... 118
7.6 Summary of Assurances Associated with Key-Agreement Schemes ............................. 119
8. Key Recovery ....................................................................................................... 122
9. Implementation Validation .................................................................................. 123
Appendix A: References ........................................................................................... 125
A.1 Normative References ................................................................................................... 125
A.2 Informative References ................................................................................................. 127
Appendix B: Rationale for Including Identifiers and other Context-specificInformation in the KDM Input (Informative) ....................................................... 129
Appendix C: Data Conversions (Normative) ........................................................... 130
C.1 Integer-to-Byte String Conversion............................................................................... 130
C.2 Field-Element-to-Byte String Conversion ................................................................... 130
C.3 Field-Element-to-Integer Conversion .......................................................................... 131
C.4 Conversion of a Bit String to an Integer ...................................................................... 131
Appendix D: Approved ECC Curves and FFC Safe-prime Groups ....................... 132
Appendix E: Revisions (Informative) ....................................................................... 134

vii

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

List of Figures
Figure 1: Owner key-establishment preparations ..........................................................................17
Figure 2: Key-agreement process. .................................................................................................18
Figure 3: Key-transport process .....................................................................................................66
Figure 4: C(2e, 2s) schemes: each party contributes a static and an ephemeral key pair ..............74
Figure 5: C(2e, 2s) scheme with unilateral key confirmation from party U to party V.................75
Figure 6: C(2e, 2s) scheme with unilateral key confirmation from party V to party U................76
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Figure 7: C(2e, 2s) scheme with bilateral key confirmation ..........................................................77
Figure 8: C(2e, 0s) schemes: each party contributes only an ephemeral key pair .........................81
Figure 9: C(1e, 2s) schemes: party U contributes a static and an ephemeral key pair while party
V contributes only a static key pair ................................................................................92
Figure 10: C(1e, 2s) scheme with unilateral key confirmation from party U to party V...............93
Figure 11: C(1e, 2s) scheme with unilateral key confirmation from party V to party U...............94
Figure 12: C(1e, 2s) scheme with bilateral key confirmation ........................................................95
Figure 13: C(1e, 1s) schemes: party U contributes an ephemeral key pair, and party V contributes
a static key pair .............................................................................................................101
Figure 14: C(1e, 1s) scheme with unilateral key confirmation from party V to party U.............102
Figure 15: C(0e, 2s) schemes: each party contributes only a static key pair ...............................103
Figure 16: C(0e, 2s) scheme with unilateral key confirmation from party U to party V.............108
Figure 17: C(0e, 2s) scheme with unilateral key confirmation from party V to party U.............109

List of Tables
Table 1: FIPS 186-type FFC parameter-size sets ..........................................................................23
Table 2: Initial assurances required by the key-pair owner ...........................................................34
Table 3: Optional renewal of assurances by the key-pair owner ...................................................34
Table 4: Assurances required by a public-key recipient ................................................................38
Table 5: Approved MAC algorithms for key confirmation ...........................................................62
Table 6: Key-agreement scheme categories ..................................................................................64
Table 7: Key-agreement scheme subcategories .............................................................................64
Table 8: Key-agreement schemes ..................................................................................................65
Table 9: dhHybrid1 key-agreement scheme summary ..................................................................69
viii

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

Table 10: Full unified model key-agreement scheme summary ....................................................71
Table 11: MQV2 key-agreement scheme summary ......................................................................72
Table 12: Full MQV key-agreement scheme summary .................................................................74
Table 13: dhEphem key-agreement scheme summary ..................................................................80
Table 14: Ephemeral unified model key-agreement scheme summary .........................................81
Table 15: dhHybridOneFlow key-agreement scheme summary ...................................................85
Table 16: One-pass unified model key-agreement scheme summary ...........................................87
Table 17: MQV1 key-agreement scheme summary ......................................................................89
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Table 18: One-pass MQV model key-agreement scheme summary .............................................91
Table 19: dhOneFlow key-agreement scheme summary ...............................................................99
Table 20: One-pass Diffie-Hellman key-agreement scheme summary .......................................101
Table 21: dhStatic key-agreement scheme summary...................................................................105
Table 22: Static unified model key-agreement scheme summary ...............................................107
Table 23: Summary of assurances ...............................................................................................121
Table 24: Appoved elliptic curves for ECC key-agreement ........................................................132
Table 25: Approved IKE groups for FFC key agreement............................................................133
Table 26: Approved TLS groups for FFC key agreement ..........................................................133

ix

NIST SP 800-56A Rev. 3

1.

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

Introduction

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Many U.S. Government Information Technology (IT) systems need to employ wellestablished cryptographic schemes to protect the integrity and confidentiality of the data thatthey process. Algorithms such as the Advanced Encryption Standard (AES) as defined inFederal Information Processing Standard (FIPS) 197,1 and the Keyed-Hash Message
Authentication Code (HMAC) as defined in FIPS 1982 make attractive choices for theprovision of these services. These algorithms have been standardized to facilitate
interoperability between systems. However, the use of these algorithms requires theestablishment of keying material between the participating entities in advance. Trusted
couriers may manually distribute this secret keying material. However, as the number ofentities using a system grows, the work involved in the distribution of the secret keying
material could grow rapidly. Therefore, it is essential to support the cryptographic algorithms
used in modern U.S. Government applications with automated key-establishment schemes.
A key-establishment scheme can be characterized as either a key-agreement scheme or a keytransport scheme. The asymmetric-key-based key-agreement schemes in thisRecommendation are based on the Diffie-Hellman (DH) and Menezes-Qu-Vanstone (MQV)
algorithms. Asymmetric-key-based key-establishment schemes using Integer Factorization
Cryptography are specified in SP 800-56B.3 The selection of schemes specified in thisRecommendation is based on standards for key-establishment schemes developed by the
Accredited Standards Committee (ASC) X9, Inc.: ANS X9.42, Agreement of Symmetric Keys
using Discrete Logarithm Cryptography, and ANS X9.63, Key Agreement and Key
Transport using Elliptic Curve Cryptography.

2.

Scope and Purpose

This Recommendation provides the specifications for key-agreement schemes that areappropriate for use by the U.S. Federal Government and is intended for use in conjunction
with NIST Special Publication (SP) SP 800-57.4 This Recommendation (i.e., SP 800-56A)
and SP 800-57 are intended to provide sufficient information for a vendor to implement
secure key establishment using asymmetric algorithms in FIPS 1405-validated modules.
A scheme may be a component of a protocol, which in turn provides additional security
properties not provided by the scheme when considered by itself. Note that protocols, per se,
are not specified in this Recommendation.

1

FIPS 197, Advanced Encryption Standard (AES).
FIPS 198, The Keyed-Hash Message Authentication Code (HMAC).
3
SP 800-56B, Recommendation for Pair-Wise Key-establishment Schemes Using Integer Factorization
Cryptography.
4
SP 800-57, Recommendation for Key Management.
5
FIPS 140, Security Requirements for Cryptographic Modules.
2

1

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

3.

Definitions, Symbols and Abbreviations

3.1

Definitions

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Algorithm

A clearly specified mathematical process for computation; a set ofrules that, if followed, will give a prescribed result.

Approved

FIPS-approved or NIST-Recommended. An algorithm or techniquethat is either 1) specified in a FIPS or NIST Recommendation, or 2)
adopted in a FIPS or NIST Recommendation and specified either (a)in an appendix to the FIPS or NIST Recommendation, or (b) in adocument referenced by the FIPS or NIST Recommendation.

Assumption

Used to indicate the conditions that are required to be true when an
approved key-establishment scheme is executed in accordance withthis Recommendation.

Assurance ofprivate-key
possession

Confidence that an entity possesses a private key corresponding to a
public key.

Assurance ofvalidity

Confidence that either a key or a set of domain parameters isarithmetically correct.

Big-endian

The property of a byte string having its bytes positioned in order ofdecreasing significance. In particular, the leftmost (first) byte is themost significant byte (containing the most significant eight bits of thecorresponding bit string) and the rightmost (last) byte is the leastsignificant byte (containing the least significant eight bits of thecorresponding bit string).
For the purposes of this Recommendation, it is assumed that the bits
within each byte of a big-endian byte string are also positioned inorder of decreasing significance (beginning with the most significant
bit in the leftmost position and ending with the least significant bit in
the rightmost position).

Binding

Assurance of the integrity of an asserted relationship between items
of information that is provided by cryptographic means. Also see
Trusted association.

Bit length

The length in bits of a bit string.

Bit string

An ordered sequence of 0’s and 1’s. Also known as a binary string.

Byte

A bit string consisting of eight bits.

Byte string

An ordered sequence of bytes.

2

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Certificate
Authority (CA)The entity in a Public-Key Infrastructure (PKI) that is responsible for
issuing public key certificates and exacting compliance to a PKI
policy. Also known as a Certification Authority.

Cofactor

The order of the elliptic curve group divided by the (prime) order ofthe generator point (i.e., the base point) specified in the domain
parameters.

Confidentiality

The property that sensitive information is not disclosed tounauthorized entities.

Critical security
parameter (CSP)

Security-related information whose disclosure or modification cancompromise the security of a cryptographic module. Domain
parameters, secret or private keys, shared secrets, key-derivation
keys, intermediate values and secret salts are examples of quantities
that may be considered CSPs in this Recommendation. See FIPS 140.

Cryptographic
key (Key)A parameter used with a cryptographic algorithm that determines its
operation.

Cryptographic
moduleThe set of hardware, software and/or firmware that implements
approved security functions (including cryptographic algorithms andkey generation). See FIPS 140.

DestroyIn this Recommendation, an action applied to a key or a piece of secretdata. After a key or a piece of secret data is destroyed, no information
about its value can be recovered. Also known as zeroization in FIPS
140.

Domainparameters

The parameters used with a cryptographic algorithm that are common
to a domain of users.

EntityAn individual (person), organization, device, or process. “Party” is asynonym.

Ephemeral key
pair

A key pair, consisting of a public key (i.e., an ephemeral public key)
and a private key (i.e., an ephemeral private key) that is intended fora very short period of use. The key pair is ordinarily used in exactly
one transaction of a cryptographic scheme. Contrast with a static key
pair.

Fresh

Newly established keying material that is statistically independent ofany previously established keying material.

Hash function

A function that maps a bit string of arbitrary length to a fixed-length
bit string. Approved hash functions are expected to satisfy thefollowing properties:

3

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

1. One-way: It is computationally infeasible to find any inputthat maps to any pre-specified output, and
2. Collision resistant: It is computationally infeasible to find any
two distinct inputs that map to the same output.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Identifier

A bit string that is associated with a person, device or organization. It
may be an identifying name or may be something more abstract (forexample, a string consisting of an IP address).

Integrity

A property whereby data has not been altered in an unauthorizedmanner since it was created, transmitted or stored.

Key agreement

A (pair-wise) key-establishment procedure in which the resultant
secret keying material is a function of information contributed by bothparticipants so that neither party can predetermine the value of thesecret keying material independently from the contributions of theother party. Contrast with key-transport.

Key-agreementtransaction

An execution of a key-agreement scheme.

Key confirmation

A procedure to provide assurance to one party (the key-confirmation
recipient) that another party (the key-confirmation provider)possesses the correct secret keying material and/or the shared secretfrom which that keying material is derived.

Key-confirmation The party that provides assurance to the other party (the recipient) thatproviderthe two parties have indeed established a shared secret or sharedkeying material.
Key-derivation
function

As used in this Recommendation, a function used to derive secet
keying material from a shared secret and other information.

Key-derivation
methodAs used in this Recommendation, a method used to derive secretkeying material from a shared secret and other information. A keyderivation method may use a key-derivation function or a keyderivation procedure.

Key-derivation
procedure

As used in this Recommendation, a multi-step process that is used toderive keying material from a shared secret and other information.

Keyestablishment

The procedure that results in secret keying material that is shared
among different parties.

Keyestablishment
key pairA private/public key pair that is used in a key-establishment scheme.
It can be a static key pair or an ephemeral key pair.

4

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Keyestablishmenttransaction

An instance of establishing secret keying material using a keyagreement or key-transport transaction.

Key-transport

A (pair-wise) key-establishment procedure whereby one party (thesender) selects a value for the secret keying material and then securely
distributes that value to another party (the receiver). Contrast with key
agreement.

Key-transporttransaction

An execution of a key-transport scheme.

Key-wrapping

A method of protecting keying material (along with associatedintegrity information) that provides both confidentiality and integrity
protection by using symmetric-key algorithms.

Key-wrappingkey

In this Recommendation, a key-wrapping key is a symmetric key
established during a key-agreement transaction and used with a keywrapping algorithm to protect the keying material to be transported.

Key-wrapping
algorithm

An algorithm for protecting keying material that provides bothconfidentiality and integrity protection using a symmetric keywrapping key.

Key-wrappingkey

A symmetric key used with a key-wrapping algorithm to protect the
keying material to be transported.

Keying material

Data that is represented as a binary string such that any nonoverlapping segments of the string with the required lengths can beused as secret keys, secret initialization vectors and other secretparameters.

MAC tag

Data obtained from the output of a MAC algorithm (possibly bytruncation) that can be used by an entity to verify the integrity and theorigination of the information used as input to the MAC algorithm.

Message
Authentication
Code (MAC)
algorithm

A family of cryptographic functions that is parameterized by asymmetric key. Each of the functions can act on input data (called a“message”) of variable length to produce an output value of a
specified length. The output value is called the MAC of the input
message. An approved MAC algorithm is expected to satisfy thefollowing property (for each of its supported security levels):
It must be computationally infeasible to determine the (as yet
unseen) MAC of a message without knowledge of the key, even
if one has already seen the results of using that key to computethe MACs of other (different) messages.
5

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

A MAC algorithm can be used to provide data-origin authenticationand data-integrity protection. In this Recommendation, a MAC
algorithm is used for key confirmation; the use of MAC algorithms
for key derivation is addressed in SP 800-56C.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Nonce

A time-varying value that has at most an acceptably small chance ofrepeating. For example, the nonce may be a random value that is
generated anew for each use, a timestamp, a sequence number, orsome combination of these.

Owner

For a static public key, static private key and/ or the static key paircontaining those components, the owner is the entity that is authorized
to use the static private key corresponding to the static public key,whether that entity generated the static key pair itself or a trusted party
generated the key pair for the entity.
For an ephemeral public key, ephemeral private key and/or orephemeral public key pair, the owner is the entity that generated theephemeral key pair and is authorized to use the ephemeral private keyof the key pair.

Party

See entity.

Prime number

An integer that is greater than 1 and divisible only by 1 and itself.

Primitive

A low-level cryptographic algorithm that is used as a basic building
block for higher-level cryptographic operations or schemes.

Private key

A cryptographic key that is kept secret and is used with a public-key
cryptographic algorithm. A private key is associated with a public
key.

Protocol

A set of rules used by two or more communicating entities that
describe the message order and data structures for informationexchanged between the entities.

ProviderA party that provides (1) a public key (e.g., in a certificate); (2)assurance, such as an assurance of the validity of a candidate public
key or assurance of possession of the private key associated with apublic key; or (3) key confirmation. Contrast with recipient.

Public key

A cryptographic key that may be made public and is used with apublic-key cryptographic algorithm. A public key is associated witha private key.

Public-key
certificate

A data structure that contains an entity’s identifier(s), the entity's
public key (including an indication of the associated set of domain
parameters) and possibly other information, along with a signature on
6

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptographythat data set that is generated by a trusted party, i.e., a certificate
authority, thereby binding the public key to the included identifier(s).

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Public-key
validation

The procedure whereby the recipient of a public key checks that the
key conforms to the arithmetic requirements for such a key in orderto thwart certain types of attacks.

Random nonce

A nonce containing a random-value component that is generated
anew for each nonce.

ReceiverThe party that receives secret keying material via a key-transporttransaction. Contrast with sender.

Recipient

A party that (1) receives a public key; or (2) obtains assurance froman assurance provider (e.g., assurance of the validity of a candidate
public key or assurance of possession of the private key
corresponding to a public key); or (3) receives key confirmation froma key-confirmation provider.

SchemeA set of unambiguously specified transformations that provide a(cryptographic) service when properly implemented and maintained.
A scheme is a higher-level construct than a primitive and a lowerlevel construct than a protocol.

Security
properties

The security features (e.g., replay protection, or key confirmation)that a cryptographic scheme may, or may not, provide.

Security strength(Also, “Bits of
security”)

A number associated with the amount of work (that is, the number ofoperations) that is required to break a cryptographic algorithm orsystem.

Sender

The party that sends secret keying material to the receiver in a keytransport transaction. Contrast with receiver.

Shall

This term is used to indicate a requirement that needs to be fulfilled
to claim conformance to this Recommendation. Note that shall may
be coupled with not to become shall not.

Shared secretA secret value that has been computed during a key-establishment
scheme, is known by both participants, and is used as input to a keyderivation method to produce keying material.

ShouldThis term is used to indicate an important recommendation. Ignoring
the recommendation could result in undesirable results. Note thatshould may be coupled with not to become should not.

Static key pair

A key pair, consisting of a private key (i.e., a static private key) and apublic key (i.e., a static public key) that is intended for use for a
relatively long period of time and is typically intended for use in
7

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

multiple key-establishment transactions. Contrast with an ephemeral
key pair.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Store-andforward

A telecommunications technique in which information is sent to anintermediate station where it is kept and later sent to the finaldestination or to another intermediate station.

Support (asecurity strength)

A security strength of s bits is said to be supported by a particular
choice of algorithm, primitive, auxiliary function, parameters (etc.)
for use in the implementation of a cryptographic mechanism if thatchoice will not prevent the resulting implementation from attaining asecurity strength of at least s bits.
In this Recommendation, it is assumed that implementation choices
are intended to support a security strength of 112 bits or more (see SP
800-576 and SP 800-131A7).

Symmetric key

A cryptographic key that is shared between two or more entities andused with a cryptographic application to process information.

Symmetric-key
algorithm

A cryptographic algorithm that uses secret keying material that isshared between authorized parties.

Targeted security
strength

The security strength that is intended to be supported by one or more
implementation-related choices (such as algorithms, primitives,
auxiliary functions, parameter sizes and/or actual parameters) for the
purpose of instantiating a cryptographic mechanism.
In this Recommendation, it is assumed that the targeted security
strength of any instantiation of an approved key-establishment
scheme has a value greater than or equal to 112 bits and less than orequal to 256 bits.

6
7

Trustedassociation

Assurance of the integrity of an asserted relationship between items
of information that may be provided by cryptographic or noncryptographic (e.g., physical) means. Also see Binding.

Trusted party

A party that is trusted by an entity to faithfully perform certain
services for that entity. An entity could be a trusted party for itself.

Trusted third
party

A third party, such as a CA, that is trusted by its clients to perform
certain services. (By contrast, the two participants in a key-

SP 800-57 Rev. 4, Recommendation for Key Management Part1: General.
SP 800-131A, Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and
Key Lengths.

8

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

establishment transaction are considered to be the first and second
parties.)
3.2

Symbols and Abbreviations

General:This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3
8

AES

Advanced Encryption Standard (as specified in FIPS 197).

AES-CMAC

The AES Cipher-based MAC mode (as specified in SP 800-38B8).

ASC

The American National Standards Institute (ANSI) AccreditedStandards Committee.

ANS

American National Standard.

ASN.1

Abstract Syntax Notation One.

C(ie)Notation for a category of key-establishment schemes in which iephemeral key pairs are used, where i ∈ {0, 1, 2}.

C(ie, js)

Notation for a subcategory of key-establishment schemes in whichi ephemeral key pairs and j static key pairs are used. In thisRecommendation, schemes in the subcategories C(0e, 2s), C(1e,2s), C(1e, 1s), C(2e, 0s), and C(2e, 2s) are defined.

CA

Certification Authority.

CDH

The cofactor ECC Diffie-Hellman key-agreement primitive.

CSP

Critical Security Parameter.

DH

The (non-cofactor) FFC Diffie-Hellman key-agreement primitive.

DLC

Discrete Logarithm Cryptography, which is comprised of both
Finite Field Cryptography (FFC) and Elliptic Curve Cryptography(ECC).

EC

Elliptic Curve.

ECC

Elliptic Curve Cryptography; the public-key cryptographic
methods using operations in an elliptic curve group.

FF

Finite Field.

FFC

Finite Field Cryptography; the public-key cryptographic methods
using operations in a multiplicative group of a finite field.

ID

The bit string denoting the identifier associated with an entity.

SP 800-38B: Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication.

9

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3KC

Key Confirmation.

KDM

Key-Derivation Method.

KM

Keying Material.

KMAC

The KECCAK-based MAC (as specified in SP 800-1859).

len(x)The bit length of the shortest base-two representation of thepositive integer x, i.e., len(x) = log2(x)+1.

MAC

Message Authentication Code.

MAC(MacKey,
MacData)

A MAC algorithm with MacKey as the key, and MacData as thedata.

MacOutputBits

The length of the MAC ouput block in bits.

MacTag

A MAC tag.

MacTagBits

The length of the MacTag in bits.

MQV

The Menezes-Qu-Vanstone key-agreement primitive.

Null

The empty bit string

RBG

Random Bit Generator.

SHA

Secure Hash Algorithm (as specified in FIPS 18010 and FIPS
20211).

TbitLen(X)A truncation function that outputs the most significant (i.e.,
leftmost) bitLen bits of the input bit string, X, when the bit lengthof X is greater than bitLen; otherwise, the function outputs X. For
example, T2(1011) = 10, T3(1011) = 101, T4(1011) = 1011, andT5(1011) = 1011.

TTP

Trusted Third Party.

U, V

Represents the two parties in a (pair-wise) key-establishment
scheme.

9

SP 800-185, SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash, and ParallelHash.
FIPS 180, Secure Hash Standard (SHS).
11
FIPS 202, SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions.
10

10NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3{}

In this Recommendation, the curly braces { } are used in thefollowing three situations: (1) {x} is used to indicate that theinclusion of x is optional; for example, the notation “Input: w {, x},y, and z” implies that the inclusion of x as an input is optional. (2)If both X and Y are binary strings, the notation of binary string“Y{||X}” implies that the concatenation of string X is optional. (3){x1, x2, …, xk} indicates a set with elements x1, x2, …, xk.

X || YThe concatenation of two bit strings X and Y. For example, 11001|| 010 = 11001010.

[a, b]The set of integers x, such that a ≤ x ≤ b.

x

The ceiling of x; the smallest integer  x. For example, 5 = 5,
5.3 = 6.

x

The floor of x; the greatest integer that does not exceed x. For
example, ⌊2.1⌋= 2, and ⌊4⌋= 4.

Z

A shared secret (represented as a byte string) that is used to derive
secret keying material using a key-derivation method.

Ze

A component of the shared secret (represented as a byte string) thatis computed using ephemeral keys in a Diffie-Hellman primitive.

Zs

A component of the shared secret (represented as a byte string) thatis computed using static keys in a Diffie-Hellman primitive.

The following notations are used for FFC and ECC in this Recommendation. Note that thenotation sometimes differs between the two scheme types due to the differing notations usedin the two standards on which this Recommendation is based (i.e., ANS X9.42 and ANS
X9.63).
FFC:
GF(p)The finite field with p elements, where p is an (odd) prime number. The
elements of GF(p) can be represented by the set of integers {0, 1, …, p−1}.
The addition and multiplication operations for GF(p) can be realized by
performing the corresponding integer operations and reducing the results
modulo p.

GF(p)*The multiplicative group of non-zero field elements in GF(p).

g

An FFC domain parameter; the selected generator of the multiplicative
subgroup of prime order q in GF(p)*.

k mod p

The modular reduction of the (arbitrary) integer k by the (positive) integerp (the modulus). For the purposes of this Recommendation, j = k mod p is
the unique integer satisfying the following two conditions:0  j < p, and k −j is a multiple of p. In short, j = k – k/p p.
11

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

p

An FFC domain parameter; an odd prime number that determines the sizeof the finite field GF(p).

counter

An optional FFC domain parameter; a value that may be output during
domain parameter generation to provide assurance at a later time that theresulting domain parameters were generated using a canonical process.

q

When used as an FFC domain parameter, q is the (odd) prime number
equal to the order of the multiplicative subgroup of GF(p)* generated by
g. Note that q is a divisor of p – 1.

r U, r V

The ephemeral private keys of party U and party V, respectively. These
are integers in the interval [1, q − 1]. (In some instances, rU, and/or rV may
be restricted to a subinterval of the form [1, 2N − 1]; see Section 5.6.1.1.1.)

t U, t V

The ephemeral public keys of party U and party V, respectively. These areintegers in the interval [2, p − 2].

SEED

An FFC domain parameter; an initialization value that is used during
domain parameter generation that can also be used later to provide
assurance that the resulting domain parameters were generated using anapproved process.

x U, x V

The static private keys of party U and party V, respectively. These areintegers in the interval [1, q − 1]. (In some instances, xU, and/or xV may be
restricted to a subinterval of the form [1, 2N − 1]; see Section 5.6.1.1.1.)

y U, y V

The static public keys of party U and party V, respectively. These areintegers in the interval [2, p − 2].

ECC:
a, b

ECC domain parameters; two elements in the finite field GF(q) that definethe (Weierstrass) equation of an elliptic curve, y2 = x3 + ax + b when q is an
odd prime p or y2 + xy = x3 + ax2 + b when q = 2m for some prime integer m.

avf(Q)

The associate value of the elliptic curve point Q.

de,U, de,V

The ephemeral private keys of party U and party V, respectively. These areintegers in the interval [1, n − 1].

ds,U, ds,V

The static private keys of party U and party V, respectively. These areintegers in the interval [1, n − 1].

FR

Field Representation indicator (an ECC domain parameter); an indication of
the basis used for representing field elements. If a polynomial basis
representation is used for a field of order 2m, then FR indicates the reduction
polynomial (a trinomial or a pentanomial); otherwise, FR is Null.
12

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3G

An ECC domain parameter, which is a distinguished (affine) point in an
elliptic curve group that generates a subgroup of prime order n.

GF(q)The finite field with q elements, where either q is an odd prime p, or q isequal to 2m for some prime integer m. The elements of GF(q) are represented
by the set of integers {0, 1, …, p − 1} in the case that q is an odd prime p,
or as bit strings of length m bits in the case that q = 2m.

h

An ECC domain parameter; the cofactor, a positive integer that is equal tothe order of the elliptic curve group, divided by the order of the cyclic
subgroup generated by the distinguished point G. That is, nh is the order ofthe elliptic curve, where n is the order of the cyclic subgroup generated by
the distinguished point G.

nAn ECC domain parameter; a prime that is the order of the cyclic subgroup
generated by the distinguished point G.

Ø

The (additive) identity element of an elliptic curve group; also called the"neutral point" of that group. Ø is the unique element satisfying Q + Ø =Ø + Q = Q for each Q in the group. For the (Weierstrass) elliptic curvegroups considered in this Recommendation, a special “point at infinity”
serves as Ø.

qWhen used as an ECC domain parameter, q is the field size. It is either an
odd prime p, or equal to 2m for some prime integer m.

Qe,U, Qe,VThe ephemeral public keys of party U and party V, respectively. These arepoints on the elliptic curve that is defined by the domain parameters.

Qs,U, Qs,V

The static public keys of party U and party V, respectively. These are points
on the elliptic curve that is defined by the domain parameters.

SEED

An optional ECC domain parameter; an initialization value that is usedduring domain parameter generation that can also be used later to provide
assurance that the resulting domain parameters were generated using anapproved process.

xP, yP

Elements of the finite field GF(q) representing the x and y coordinates,
respectively, of a point P.

13

NIST SP 800-56A Rev. 3

4.

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

Overview of Key-Establishment Schemes

Secret cryptographic keying material may be electronically established between parties byusing a key-establishment scheme, that is, by using either a key-agreement scheme or a keytransport scheme. This Recommendation specifies key-agreement schemes; however,Section 4.3 discusses how key transport may be conducted using the keying material derived
during a key-agreement transaction.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

During a pair-wise key-agreement scheme, the secret keying material to be established is notsent directly from one entity to another. Instead, the two parties exchange information fromwhich they each compute a shared secret that is used (along with other exchanged/knowndata) to derive the secret keying material. The method used to combine the information madeavailable to both parties provides assurance that neither party can control the output of the
key-agreement process.
The key-agreement schemes described in this Recommendation employ public-key
techniques utilizing Discrete Logarithm Cryptography (DLC). The security of these DLCbased key-agreement schemes depends upon the intractability of the discrete logarithm
problem in certain settings.
In this Recommendation, the approved key-agreement schemes are described in terms of
the roles played by parties “U” and “V.” These are specific labels that are used to distinguishbetween the two participants engaged in key agreement – irrespective of the actual labelsthat may be used by a protocol employing a given approved key-agreement scheme.
To be in conformance with this Recommendation, a protocol employing any of the approved
pair-wise key-agreement schemes shall unambiguously assign the roles of party U and party
V to the participants by clearly defining which participant performs the actions ascribed bythis Recommendation to party U, and which performs the actions ascribed herein to party V.
This Recommendation specifies several processes that are associated with key establishment(including processes for generating domain parameters and for deriving secret keying
material from a shared secret). Some of these processes are used to provide assurance (forexample, assurance of the arithmetic validity of a public key or assurance of the possessionof a private key associated with a public key). The party that provides the assurance is called
the “provider” (of the assurance), and the party that obtains the assurance is called the“recipient” (of the assurance). For any of the specified processes, equivalent processes may
be used. Two processes are equivalent if, when the same values are input to each process(either as input parameters or as values made available during the process), the same output
is produced.
The security of a key-establishment scheme depends on its implementation, and thisdocument includes several practical recommendations for implementers. For example, good
security practice dictates that implementations of procedures employed by primitives,operations, schemes, etc. include steps that destroy any potentially sensitive locally stored
data that is created (and/or copied for use) during the execution of a given procedure, andwhose continued local storage is not required after the procedure has been exited. The
destruction of such locally stored data ideally occurs prior to or during any exit from theprocedure. This is intended to limit opportunities for unauthorized access to sensitive
14

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

information that might compromise a key-establishment process and to prevent its use forany other purpose.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Explicit instructions for the destruction of certain potentially sensitive values that are likely
to be locally stored by procedures are included in the specifications found in thisRecommendation. Examples of such values include local copies of any portions of secret or
private keys that are employed or generated during the execution of a procedure, intermediate
results produced during computations, and locally stored duplicates of values that are
ultimately output by a procedure. However, it is not possible to anticipate the form of all
possible implementations of the specified primitives, operations, schemes, etc., making it
impossible to enumerate all potentially sensitive data that might be locally stored by aprocedure employed in a given implementation. Nevertheless, the destruction of any
potentially sensitive locally stored data is an obligation of all implementations.
Sections 4.1 and 4.2 describe the various steps that may be performed to establish secretkeying material during key agreement.
4.1

Key Establishment Preparations

The owner of a private/public key pair is the entity that is authorized to use the private keyof that key pair. The precise steps required may depend upon the key-establishment schemeand the type of key pair (static or ephemeral).
The first step is to obtain appropriate domain parameters, as specified in Section 5.5.1 froman approved list (see Appendix D) or (in the FFC case) generated as specified in Section 5.5
by a trusted party. These parameters will determine the type of arithmetic used to generate
key pairs and compute shared secrets. The owner must have assurance of the validity of these
domain parameters; approved methods for obtaining this assurance are provided in Section
5.5.2.
If the owner will be using a key-establishment scheme that requires that the owner have astatic key pair, the owner obtains this key pair. Either the owner or a trusted third party
generates the key pair as specified in Section 5.6.1. If the key pair is generated by a trusted
third party, then the key pair shall be transported to the owner in a protected manner(providing source authentication and integrity protection for the entire key pair, andconfidentiality protection of (at least) the private key). If the key-establishment scheme
requires an ephemeral key pair, the owner generates it (as close to the time of use as possible)
as specified in Section 5.6.1. Before using a static or ephemeral key pair in a keyestablishment transaction, its owner is required to confirm its validity by obtaining theassurances specified in Section 5.6.2.1.
An identifier is used to label the entity that owns a static key pair used in a key-establishmenttransaction; an identifier may also be used to label the owner of an ephemeral key pair. Thislabel may uniquely distinguish the owner from all other entities, in which case it could
rightfully be considered an identity. However, the label may be something less specific – anorganization, nickname, etc. – hence, the term identifier is used in this Recommendation,rather than the term identity. For example, an identifier could be “NIST123”, rather than an
identifier that names a given person. A key pair’s owner (or an agent trusted to act on the
15

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

owner’s behalf) is responsible for ensuring that an identifier associated with its static public
key is appropriate for the applications in which it will be used.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

For each static key pair, this Recommendation assumes that there is a trusted association
between the owner’s identifier(s) and the owner’s static public key. The association may beprovided using cryptographic mechanisms or by physical means. The use of cryptographic
mechanisms may require the use of a binding authority (i.e., a trusted authority) that binds
the information in a manner that can be verified by others; an example of such a trusted
authority is a registration authority working with a CA who creates a certificate containing
both the static public key and the identifier. The binding authority shall verify the owner’s
intent to associate a specific identifier chosen for the owner and the public key; the means
for accomplishing this is beyond the scope of this Recommendation. The binding authority
shall also obtain assurance of the validity of the domain parameters associated with theowner’s key pair, the arithmetic validity of the owner’s static public key, and the owner’s
possession of the static private key corresponding to that static public key (see Section 5.5.2,
Section 5.6.2.2.1 [method 1], and Section 5.6.2.2.3, respectively.)
As an alternative to reliance upon a binding authority, trusted associations between
identifiers and static public keys may be established by the direct exchange of thisinformation between entities using a mutually trusted method (e.g., a trusted courier or aface-to-face exchange). In this case, each entity receiving an identifier and the associatedstatic public key shall be responsible for obtaining the same assurances that would have beenobtained on their behalf by a binding authority (see the previous paragraph). Entities shallalso be responsible for maintaining (by cryptographic or other means) the trusted associations
between any identifiers and static public keys received through such exchanges.
If an entity engaged in a key-establishment transaction owns a static key pair that is employedduring the transaction, then the identifier used to label that party shall be one that has atrusted association with the static public key of that key pair. If an entity engaged in a keyestablishment transaction contributes only an ephemeral public key during the transaction,
but an identifier is still desired/required for that party, then a non-null identifier shall beselected/assigned in accordance with the requirements of the protocol relying upon thetransaction.
Figure_1 depicts the steps that may be required of an owner to obtain its key pair(s) in
preparation for key establishment.

16

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

Obtain domain
parameters(5.5.1)
Obtain assurance ofdomain parameter
validity (5.5.2)
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Obtain static key
pair (5.6.1)

Generate
ephemeral key pair(5.6.1)
Schemedependent

Establish trusted
association withidentifiers (4.1)
Obtain required
assurances (5.6.2)

Ready for key establishment

Figure 1: Owner key-establishment preparations
4.2

Key-Agreement Process

A key-agreement process specified in this Recommendation consists of a sequence ofordered steps. Figure 2 depicts the steps that may be required of an entity when establishingsecret keying material with another entity using one of the key-agreement schemes described inthis Recommendation. Some discrepancies in the order of the steps may occur, depending
upon the communication protocol in which the key-agreement process is performed.
Depending on the key-agreement scheme and the available keys, the party whose actions aredescribed could be either of the two participants in the key-agreement scheme (i.e., either
party U or party V).

17

NIST SP 800-56A Rev. 3
Figure 2: Key-agreement
process

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Obtain other party’s
static public key

Receive otherparty’s ephemeral
public key and/or
other public data

Generate a nonce
and/or an ephemeral
key pair(5.4 & 5.6.1)

Obtain required
assurance for otherparty’s static publickey (5.6.2.2)

Obtain required
assurance for otherparty’s ephemeral
public key (5.6.2.2)

Provide ephemeral
public key and/or
other public data toother party

Complete key
confirmation(5.9 & 6)

Obtain assurance ofpossession ofprivate keys
(5.6.2.2)

Generate sharedsecret and derive
keying material(6 & 5.8)

Destroy sharedsecret, ephemeral
private key,
MacKey, etc.

Key agreement completedFigure 2: Key-agreement process.
Note that some of the actions shown in Figure 2 may be absent from certain schemes. The
specifications of this Recommendation indicate when an action is required.
If required by the key-agreement scheme, a party generates an ephemeral key pair (inaccordance with Section 5.6.1) and provides the ephemeral public key of that key pair to theother entity; the ephemeral private key is not provided to the other party.
If required or desired for use in the key-agreement transaction, a party generates a nonce (asspecified in Section 5.4) and provides it to the other party.
Depending upon the circumstances, additional public information (e.g., a party’s static public
key, an identifier, etc.) may be provided to or obtained from the other party.
18

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

If required by the key-agreement scheme, a party that requires the other entity’s static public
key acquires that key (as well as the associated identifier) and obtains assurance of its
validity. Approved methods for obtaining assurance of the validity of the other entity’s static
public key are provided in Section 5.6.2.2.1. Assurance that the other entity is in possessionof the corresponding static private key must also be obtained prior to using the derived keying
material for purposes beyond those of the key-agreement transaction itself. (Note: thisrestriction does not prohibit the use of derived keying material for key confirmation
performed during the key-agreement transaction.) See Section 5.6.2.2.3 for approved
methods for obtaining this assurance.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

If a party receives an ephemeral public key from the other entity for use in the key-agreementtransaction, that party must obtain assurance of its validity. Approved methods for obtaining
assurance of the validity of the other entity’s ephemeral public key are provided in Section
5.6.2.2.2.
If either of the participants in the key-agreement transaction requires evidence that the otherparticipant has computed the same shared secret and/or derived the same secret keying
material, (unilateral or bilateral) key confirmation may be performed as specified in Section
5.9.
4.3

DLC-based Key-Transport Process

Key transport is a key-establishment procedure whereby one party (the sender) selects avalue for the secret keying material and then securely distributes that value to another party(the receiver). Key transport may be performed using an approved key-wrapping algorithm(see SP 800-38F12) and a key-wrapping key established during the execution of a keyagreement scheme specified in Section 6. The security properties for this key-establishment
process depend on the key-agreement scheme, key-wrapping algorithm and communication
protocol used; the roles assumed by the participants during the process; and all otherparameters used.

12

SP 800-38F, Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping.

19

NIST SP 800-56A Rev. 3

5.

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

Cryptographic Elements

This section describes the basic computations that are performed and the assurances that need
to be obtained when performing DLC-based key establishment. The schemes described in
Section 6 are based upon the correct implementation of these computations and assurances.
5.1

Cryptographic Hash Functions

In this Recommendation, cryptographic hash functions may be used in key derivation and in
MAC-tag computation during key confirmation. An approved hash function shall be used
when a hash function is required. FIPS 180 and FIPS 202 specify approved hash functions.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

5.2

Message Authentication Code (MAC) Algorithm

A Message Authentication Code (MAC) algorithm defines a family of cryptographic
functions that is parameterized by a symmetric key. It is computationally infeasible todetermine the MAC of a (newly formed) MacData value without knowledge of the MacKey
value (even if one has seen the MACs corresponding to other MacData values that werecomputed using that same MacKey value).
The input to a MAC algorithm includes a symmetric key, called MacKey and a binary data
string called MacData that serves as the “message.” That is, a MAC computation isrepresented as MAC(MacKey, MacData). In this Recommendation, a MAC algorithm is used
if key confirmation is performed during key establishment (see Section 5.9); a (possibly
different) MAC algorithm may be used for the required key-derivation process (see Section
5.8 and SP 800-56C).
Key confirmation requires the use of an approved MAC algorithm, i.e., HMAC, AESCMAC or KMAC. HMAC is specified in FIPS 198 and requires the use of an approved hashfunction. AES-CMAC is specified in SP 800-38B for the AES block cipher algorithm
specified in FIPS 197. KMAC is specified in SP 800-185.
When used for key confirmation, an entity is required to compute a MAC tag on received orderived data using a MAC algorithm with a MacKey that is derived from a shared secret. The
MAC tag is sent to the other entity participating in the key-establishment scheme in order toprovide assurance that the shared secret or derived keying material was correctly computed.
MAC-tag computation and verification are defined in Sections 5.2.1 and 5.2.2.
If a MAC algorithm is employed in key derivation, an approved MAC algorithm shall beselected and used in accordance with SP 800-56C.
5.2.1 MAC Tag Computation for Key Confirmation
Key confirmation can be performed as part of a key-agreement scheme.
The computation of a MAC tag (denoted MacTag) is represented as follows:
MacTag = TMacTagBits[MAC(MacKey, MacData)].
To compute a MacTag:

20

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

1. The agreed-upon MAC algorithm (see Section 5.2) is used with MacKey to computethe MAC of MacData, where MacKey is a symmetric key, and MacData represents
the input “message” data. The minimum length of MacKey is specified in Table 5 ofSection 5.9.3.
MacKey is obtained from the DerivedKeyingMaterial (when a key-agreement scheme
employs key confirmation), as specified in Section 5.9.1.
The output of the MAC algorithm is a bit string whose length (in bits) is
MacOutputBits.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

2. Those bits are input to the truncation function TMacTagBits, which returns the leftmost(i.e., initial) bits of MacTagBits to be used as the value of MacTag. MacTagBits shallbe less than or equal to MacOutputBits. (When MacTagBits equals MacOutputBits,
TMacTagBits acts as the identity function.) The minimum value for MacTagBits is 64, as
specified in Section 5.9.3.
5.2.2 MAC Tag Verification for Key Confirmation
To verify a received MacTag (i.e., received during key confirmation), a new MAC tag,
MacTag is computed using the values of MacKey, MacTagBits, and MacData possessed by
the recipient (as specified in Section 5.2.1). MacTag is compared with the received MacTag.
If their values are equal, then it may be inferred that the same MacKey, MacTagBits, andMacData values were used in the two MAC tag computations.
5.3

Random Number Generation

Whenever this Recommendation requires the use of a randomly generated value (forexample, for obtaining keys or nonces), the values shall be generated using an approved
random bit generator that supports the targeted security strength (see the SP 800-9013 seriesof publications).
5.4

Nonce

A nonce is a time-varying value that has an acceptably small chance of repeating (where themeaning of “acceptably small” may be application specific). In certain schemes specified inthis Recommendation, a party may be required to provide a (public) nonce that is used for
key-agreement and/or key-confirmation purposes. This circumstance arises when a scheme
does not require that a party provide an ephemeral public key to the other party as part of the
key-establishment process.
This Recommendation requires the use of a nonce (supplied by Party U) in the C(0e, 2s) keyagreement schemes specified in Section 6.3. A nonce (supplied by party V) is also requiredby the C(1e, 2s) and C(0e, 2s) schemes when party V obtains key confirmation from party U

13

SP 800-90A, Recommendation for Random Number Generation Using Deterministic Random Bit
Generators; SP800-90B, Recommendation for the Entropy Sources Used for Random Bit Generation; SP
800-90C, Recommendation for Random Bit Generator (RBG) Constructions.

21

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

in conformance with this Recommendation (see Section 6.2.1.5 and Section 6.3.3,
respectively).
A nonce may be composed of one (or more) of the following components (other components
may also be appropriate):
1. A random bit string that is generated anew for each nonce, using an approved
random bit generator. A nonce containing a component of this type is called a random
nonce.
2. A timestamp of sufficient resolution so that it is different each time it is used.
3. A monotonically increasing sequence number, orThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

4. A combination of a timestamp and a monotonically increasing sequence number,such that the sequence number is reset when and only when the timestamp changes.
(For example, a timestamp may show the date but not the time of day, so a sequencenumber is appended that will not repeat during a particular day.)The specified use of a nonce in key-derivation and/or key-confirmation computations does
not provide the same benefits as the use of an ephemeral key pair in a key-agreement scheme.
(For example, party U’s contribution of a public nonce during the execution of a C(0e, 2s)
scheme does not protect the secrecy of derived keying material against a future compromiseof party U’s static private key, but the use of an ephemeral key pair by party U during theexecution of a C(1e, 2s) scheme can provide such protection.) Still, the contribution of an
appropriately formed nonce can support some of the security goals (e.g., assurance of the
freshness of derived keying material) that might otherwise be supported by the contributionof an ephemeral public key generated (and used) in conformance with this Recommendation.
Whenever a nonce is required for key-agreement and/or key-confirmation purposes as
specified in this Recommendation, it should be a random nonce containing a random bit
string output from an approved random bit generator, where both the security strength
supported by the instantiation of the random bit generator and the bit length of the random
bit string are greater than or equal to the targeted security strength of the key-agreement
scheme in which the nonce is used; when feasible, the bit length of the random bit
string should be (at least) twice the targeted security strength.
For details concerning the security strength supported by an instantiation of a random bit
generator, see SP 800-90.
As part of the proper implementation of this Recommendation, system users and/or agentstrusted to act on their behalf should determine that the components selected for inclusion in
any required nonces meet their security requirements. The application tasked withperforming key establishment on behalf of a party should determine whether to proceed witha key-establishment transaction, based upon the perceived adequacy of the method(s) used
to form the required nonces. Such knowledge may be explicitly provided to the application
in some manner, or may be implicitly provided by the operation of the application itself.

22

NIST SP 800-56A Rev. 3

5.5

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

Domain Parameters

Discrete Logarithm Cryptography (DLC), which includes Finite Field Cryptography (FFC)and Elliptic Curve Cryptography (ECC), requires that the public and private key pairs be
generated with respect to a set of domain parameters.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Both parties executing a key-establishment scheme shall have assurance of domainparameter validity prior to using them (e.g., to generate key pairs). Although domain
parameters are public information, they shall be managed so that the correct correspondence
between a given key pair and its set of domain parameters is maintained for all parties that
use the key pair. Domain parameters may remain fixed for an extended period, and one setof domain parameters may be used with multiple key pairs and with multiple keyestablishment schemes.
For this Recommendation, only one set of domain parameters shall be used during any keyestablishment transaction. That is, when a key-establishment scheme uses both a static key
pair and an ephemeral key pair, they shall be generated using the same set of domain
parameters.
5.5.1 Domain-Parameter Selection/Generation
5.5.1.1 FFC Domain Parameter Selection/Generation
If p is a prime number, then GF(p) denotes the finite field with p elements, which can be
represented by the set of integers {0, 1, …, p − 1}. The addition and multiplication operations
for GF(p) can be realized by performing the corresponding integer operations and reducing
the results modulo p. The multiplicative group of non-zero field elements is denoted by
GF(p)*. In this Recommendation, an FFC key-establishment scheme requires the use of
public keys that are restricted to a (unique) cyclic subgroup of GF(p)* with prime order q(where q divides p – 1). If g is a generator of this cyclic subgroup, then its elements can be
represented as {1, g mod p, g2 mod p, …, gq−1 mod p}, and 1 = gq mod p.
Domain parameters for an FFC scheme are of the form (p, q, g{, SEED, counter}), where pis the (odd) prime field size, q is an (odd) prime divisor of p – 1, and g is a generator of thecyclic subgroup of GF(p)* of order q. The optional parameters, SEED and counter, aredescribed below.
Two classes of domain parameters are approved for FFC key agreement: a class of “safe”
domain parameters that are associated with approved safe-prime groups, and a class of“FIPS 18614-type” domain parameters that conform to one of the FIPS 186-type parametersize sets that are listed in Table 1.
The safe-prime groups approved for use by U.S. Government applications are listed inAppendix D. The associated domain parameters have the form (p, q = (p – 1)/2, g = 2) for
specific choices of p. (There are no SEED or counter values required for these groups as
there are for the FIPS 186-type groups; see below.) Appendix D specifies the security
strengths that can be supported by the approved safe-prime groups.
14

FIPS 186, Digital Signature Standard (DSS).

23NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

The generation of FIPS 186-type domain parameters conforming to parameter-size set FB or
FC from Table 1 shall be performed as specified in Appendix A of FIPS 186.15 The resulting
domain parameters are of the form (p, q, g{, SEED, counter}), where SEED and counter are
parameters used in an approved process for generating and validating p, q, and possibly g(depending on the method of generation). The party that generated the domain parameters
should retain SEED and counter and make them available upon request for domainparameter validation.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

When the targeted security strength for key establishment is greater than 112 bits, anapproved safe-prime group capable of supporting that security strength shall be used. Whenthe targeted security strength is 112 bits, an approved safe-prime group should be used.
FIPS 186-type domain parameters should only be used for backward compatibility withexisting applications that cannot be upgraded to use the approved safe-prime groups.
Table 1: FIPS 186-type FFC parameter-size
sets16FB

FC

Targeted security strength (in bits)
Bit length of field size p (i.e., len(p))
Bit length of subgroup order q (i.e., len(q))

112
2048
224

112
2048
256

In the binary representation of each of the odd primes p and q, both the leftmost bit and therightmost bit shall be a 1 (i.e., no padding is permitted to artificially increase the bit lengthsof their representations).
The (safe or FIPS 186-type) domain parameters used for FFC key agreement shall beselected in accordance with the targeted security strength of the relying key-establishment
scheme. SP 800-57 provides guidance on determining security strengths that are appropriate
for FFC key agreement.
5.5.1.2 ECC Domain-Parameter Selection
For ECC, let GF(q) denote the finite field with q elements, where either q is an odd prime p,
or q is equal to 2m for some prime integer m. For the purposes of this Recommendation,
an elliptic curve defined over GF(q) is assumed to be defined by either an equation of theform y2 = x3+ax+b (when q = p) or by an equation of the form y2+xy = x3+ax2+b (when q= 2m), where a and b are (appropriately chosen) elements of GF(q). In such an equation, theindicated arithmetic is performed in GF(q). (See SECG or SP 800-18617 for further
information concerning arithmetic in finite fields.) For the purposes of this Recommendation,
15

Note that the generation of the domain parameters for FFC key establishment is performed using themethods for the generation of DSA domain parameters.
16

An additional parameter-size set (FA) that provides a maximum security strength of 80 bits is no longer
approved for use (see SP 800-57 and SP 800-131A).

17

The recommended elliptic curves now listed in FIPS 186 will be moved to SP 800-186. Until SP 800-186 is
published, the recommended elliptic curves should be taken from FIPS 186-4.

24

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

an affine point P on the corresponding elliptic curve is one that can be represented as anordered pair (xP, yP) whose coordinates are elements of GF(q) that satisfy the given equation.
The set of elliptic curve points forms a group, given an appropriate binary operation “+”(elliptic-curve addition, as defined by the well-known secant-and-tangent rules) and theintroduction of a special "point at infinity" to serve as “Ø” (the additive identity element).
(See SECG or SP 800-186 for the details of elliptic-curve group operations.)
As specified in this Recommendation, an ECC key-establishment scheme requires the use of
public keys that are affine elliptic-curve points chosen from a specific cyclic subgroup withprime order n. Suppose that the point G is a generator for this cyclic subgroup. If, for eachpositive integer d, dG denotes
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

G + G +…+ G,
d terms
where “+” is the elliptic-curve addition operation, then the elements of the cyclic subgroupcan be represented as {Ø, G, 2G,…, (n – 1)G}. Note that nG = Ø. The full elliptic-curvegroup has order nh, where the integer h is called a cofactor of the cyclic subgroup generated
by G.
Domain parameters for an ECC scheme have the form (q, FR, a, b{, SEED}, G, n, h). The
parameter q is the field size. As noted above, q may be an odd prime p, or q may be equal to
2m for some prime integer m. The field representation parameter FR is used to provide
additional information (as specified in ANS X9.63 or the SECG) concerning the method used
to represent elements of the finite field GF(q). FR is Null if q is equal to an odd prime p. In
this case, the elements of the finite field are represented by the integers 0 through p – 1. Whenq = 2m, the elements of GF(2m) are represented by bit strings of length m, with each bit
indicating the coefficient (0 or 1) of a specific element of a particular basis for GF(2m) viewed
as a vector space over GF(2). FR is Null if q = 2m and the representation of field elements
corresponds to a Gaussian normal basis for GF(2m) (as specified in SP 800-186). If q = 2m,
and the representation of field elements corresponds to a polynomial basis (as specified in
SECG or SP 800-186), then FR specifies the reduction polynomial – either a trinomial or apentanomial. The parameters a and b are elements of GF(q) that define the equation of anelliptic curve. G = (xG, yG) is an affine point on the elliptic curve determined by a and b thatis used to generate a cyclic subgroup of prime order n. The parameter h is the cofactor of thecyclic subgroup generated by G. The bit string SEED is an optional parameter used in an
approved process for generating and validating a, b, and possibly G (depending on themethod of generation).
The ECC domain parameters for key establishment for U.S. Government applications shallbe selected only from the elliptic-curve domain parameters in SP 800-186 that are listed inAppendix D, along with the security strengths that can be supported by each curve. The
curves to be used for ECC key agreement shall be selected in accordance with the targeted
security strength of the relying key-establishment scheme. SP 800-57 provides guidance on
determining the security-strength requirements that are appropriate for ECC key agreement.

25

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

5.5.2 Assurances of Domain-Parameter Validity
Secure key establishment depends on the arithmetic validity of the domain parameters usedby the parties. Therefore, each party shall have assurance of the validity of candidate domain
parameters before they are used for key establishment. Each party shall obtain assurance thatthe candidate domain parameters are valid in one of the following ways:
1. The domain parameters correspond to a specifically approved group:a. For FFC: An approved safe-prime group, as listed in Appendix D.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

b. For ECC: An elliptic-curve group approved for use by the key-establishment
schemes specified in this Recommendation, as listed in Appendix D and specified
in SP 800-186.18
2. For FFC domain parameters that conform to a FIPS 186-type parameter-size set (seeTable 1):a. The party has generated the domain parameters using a method specified inAppendix A of FIPS 186 and/or
b. The party has performed an explicit domain-parameter validation as specified in
SP 800-8919,20, using the provided SEED and counter values.
(Method b can be used by the party that generated the FFC domain parameters to
obtain renewed assurance of their validity, as necessary.)
3. A trusted third party (for example, a CA) has obtained assurance that the domain
parameters are valid in accordance with one of the methods above, and has
communicated that fact through a trusted channel.
As part of the proper implementation of this Recommendation, system users and/or agentstrusted to act on their behalf should determine which of the methods above meet theirsecurity requirements. The application tasked with performing key establishment on behalfof a party should determine whether to proceed with a key-establishment transaction, based
upon the perceived adequacy of the method(s) used to obtain assurance of domain-parameter
validity. Such knowledge may be explicitly provided to the application in some manner, or
may be implicitly provided by the operation of the application itself.
5.5.3 Domain Parameter Management
The set of domain parameters used shall be protected against modification or substitution
until the set is deactivated (if it is no longer needed). Each private/public key pair shall becorrectly associated with its specific set of domain parameters.

18

SP 800-186, Recommendations for Discrete Logarithm-Based Cryptography Elliptic Curve Domain
Parameters. Specified in FIPS 186-4 until SP 800-186 is available.
19
SP 800-89, Recommendation for Obtaining Assurances for Digital Signature Applications.
20
Note that the validation of the FFC domain parameters uses the same methods as are used for the DSA
domain parameters.

26

NIST SP 800-56A Rev. 3

5.6

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

Key-Establishment Key Pairs

This section specifies requirements for the generation of key pairs to be used in keyestablishment transactions, provides methods for obtaining assurances that valid key pairs
are used during key establishment, and specifies key-management requirements for the staticand ephemeral key pairs used in key establishment.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

5.6.1 Key-Pair Generation
These generation methods assume the use of valid domain parameters (see Section 5.5). Prior
to performing key-pair generation with the selected domain parameters, the party generating
the key pair shall obtain assurance of domain-parameter validity in accordance with Section
5.5.2.
5.6.1.1 FFC Key-Pair Generation
Each FFC static and ephemeral key pair shall be generated using an approved method (seeSection 5.6.1.1.3 or 5.6.1.1.4) and the selected valid domain parameters (p, q, g{, SEED,
counter}).
5.6.1.1.1 Using the Approved Safe-Prime Groups

When the domain parameters (p, q = (p – 1)/2, g = 2) correspond to an approved safe-primegroup (named in Appendix D), private keys are integers in the the interval [1, q – 1] whosebinary representations require no more than N bits, for an appropriate choice of N, and thecorresponding public keys are in the interval [2, p – 2]. For the key-pair generation methods
in Sections 5.6.1.1.3 and 5.6.1.1.4, the value of the input parameter s shall be the largest
security strength that can be supported by the named safe-prime group, and the value for the
input parameter N (the requested maximum bit length of the private key) shall satisfy theinequalities 2s  N  len(q). The generated key pairs shall be used only for key-agreement
purposes (see Section 6 for the approved key-agreement schemes).
5.6.1.1.2 Using the FIPS 186-Type FFC Parameter-size Sets

When the domain parameters (p, q, g{, SEED, counter}) conform to a FIPS 186-type FFC
parameter-size set (see Table 1), private keys are generated in the interval [1, q – 1], and thecorresponding public keys are in the interval [2, p – 2]. For the key-pair generation methods
in Sections 5.6.1.1.3 and 5.6.1.1.4, the value used for the input parameter N shall be len(q),i.e., the bit length of the domain parameter q, and the value used for the input parameter s
shall be 112, which is the security strength that can be supported by the FIPS 186-type FFC
parameter-size set that was used to generate the domain parameters (see Table 1). The
generated key pairs shall be used only for key-agreement purposes (see Section 6 for theapproved key-agreement schemes), with the possible exception discussed in item 5 ofSection 5.6.3.2.
5.6.1.1.3 Key-Pair Generation Using Extra Random Bits

In this method, 64 more bits are requested from the random bit generator (RBG) than areneeded for the private key so that bias produced by the mod function in process step 5 is
negligible.
27

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

The following process or its equivalent may be used to generate an FFC key pair.
Input:
1. (p, q, g)

The FFC domain parameters used by this process. p, q and g shalleither be provided as integers during input, or shall be converted tointegers prior to use.

2. N

The (maximum) bit length of the private key to be generated.

3. s

The maximum security strength to be supported by the key pair.

Output:
1. status
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

2.

(x, y)The status returned from the key-pair generation process. The statuswill indicate SUCCESS or an ERROR.
The generated private and public keys. If an error is encounteredduring the generation process, invalid values for x and y should be
returned, as represented by Invalid_x and Invalid_y in the following
specification; for example, both Invalid_x and Invalid_y could be 0.
Otherwise, x and y are returned as integers. The generated private key
x is in the interval [1, min(2N − 1, q − 1)], and the public key y is in theinterval [2, p – 2].

Process:
1. If s is not the maximum security strength that can be supported by (p, q, g), thenreturn an ERROR indication as the status and (Invalid_x, Invalid_y) as the key
pair; then exit the process without performing the remaining steps.
2. If ((N < 2s) or (N > len(q)), then return an ERROR indication as the status and(Invalid_x, Invalid_y) as the key pair; then exit the process without performing
the remaining steps.
3. Obtain a string of N + 64 returned_bits using an RBG with a security strength ofs bits or more (see Section 5 in SP 800-13321). If an ERROR indication isreturned, then return an ERROR indication as the status and (Invalid_x,
Invalid_y) as the key pair; then exit the process without performing the remaining
steps.
4. Convert returned_bits to the (non-negative) integer c in the interval[0, 2(N + 64) – 1] (see Appendix C.4).
5. Set M = min(2N, q), the minimum of 2N and q.
6. Set x = (c mod (M – 1)) + 1.
7. Set y = gx mod p.
8. Return SUCCESS as the status and (x, y) as the key pair.
Output: SUCCESS and (x, y), or21

SP 800-133, Recommendation for Cryptographic Key Generation.

28

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

an ERROR indication and (Invalid_x, Invalid_y).
5.6.1.1.4 Key-Pair Generation by Testing Candidates

In this method, a random number is obtained and tested to determine whether it will produce
a value for the private key in the correct interval. If the private key would be outside theinterval, then another random number is obtained (i.e., the process is iterated until an
acceptable value for the private key is obtained).
The following process or its equivalent may be used to generate an FFC key pair.
Input:
1. (p, q, g)This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

The FFC domain parameters used by for this process. p, q and g shalleither be provided as integers during input, or shall be converted tointegers prior to use.

2. N

The (maximum) bit length of the private key to be generated.

3. s

The maximum security strength to be supported by the key pair.

Output:
1. status2.

(x, y)The status returned from the key-pair generation process. The statuswill indicate SUCCESS or an ERROR.
The generated private and public keys. If an error is encounteredduring the generation process, invalid values for x and y should be
returned, as represented by Invalid_x and Invalid_y in the following
specification; for example, both Invalid_x and Invalid_y could be 0.
Otherwise, x and y are returned as integers. The generated private key
x is in the interval [1, min(2N − 1, q − 1)], and the public key y is in theinterval [2, p – 2].

Process:
1. If s is not the maximum security strength that can be supported by (p, q, g), thenreturn an ERROR indication as the status and (Invalid_x, Invalid_y) as the key
pair; then exit the process without performing the remaining steps.
2. If ((N < 2s) or (N > len(q)), then return an ERROR indication as the status and(Invalid_x, Invalid_y) as the key pair; then exit the process without performing
the remaining steps.
3. Obtain a string of N returned_bits using an RBG with a security strength of s bits
or more (see Section 5 of SP 800-133). If an ERROR indication is returned, thenreturn an ERROR indication as the status and (Invalid_x, Invalid_y) as the key
pair; then exit the process without performing the remaining steps.
4. Convert returned_bits to the (non-negative) integer c in the interval[0, 2N – 1] (see Appendix C.4).
5. Set M = min(2N, q), the minimum of 2N and q.
6. If (c > M – 2), then go to step 3.
7. x = c + 1.
29

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

8. y = gx mod p.
9. Return SUCCESS as the status and (x, y) as the key pair.
Output: SUCCESS and (x, y), oran ERROR indication and (Invalid_x, Invalid_y).
5.6.1.2 ECC Key-Pair Generation

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

For the ECC schemes, each static and ephemeral private key d and public key Q shall be
generated using an approved method (see Section 5.6.1.2.1 and 5.6.1.2.2) and domain
parameters that have been selected in accordance with Section 5.5.1.2. For the key-pair
generation methods in Sections 5.6.1.2.1 and 5.6.1.2.2, the value of the input parameter s
shall be the maximum security strength that can be supported by the corresponding ellipticcurve group, as specified in Appendix D.
Given valid domain parameters, each valid private key d is an integer that is randomly
selected in the interval [1, n−1]. Whether static or ephemeral, each valid public key Q isrelated to the corresponding (valid) private key d by the following formula: Q = (xQ, yQ) =dG.
5.6.1.2.1 Key Pair Generation Using Extra Random Bits

In this method, 64 more bits are requested from the RBG than are needed for d so that bias
produced by the mod function in step 6 is negligible.
The following process or its equivalent may be used to generate an ECC key pair.
Input:
1. (q, FR, a, b {, domain_parameter_seed}, G, n, h)
The ECC domain parameters that are used for this process. n is a prime
number, and G is a point on the elliptic curve (with additive order n).
2. s

The maximum security strength to be supported by the key pair.

Output:
1. status The status returned from the key-pair generation procedure. The statuswill indicate SUCCESS or an ERROR.
2.

(d, Q) The generated private and public keys. If an error is encountered during
the generation process, invalid values for d and Q should be returned, as
represented by Invalid_d and Invalid_Q in the following specification; forexample, Invalid_d and Invalid_Q could be a point that is not on theelliptic curve defined by the domain parameters. The private key d is an
integer in the interval [1, n – 1], and Q is an elliptic curve point.

Process:
1. If the domain parameters are not approved, then return an ERROR indication as
the status and (Invalid_d, Invalid_Q) as the key pair; then exit the process without
performing the remaining steps.
30

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

2. If s is not the maximum security strength that can be supported by the domain
parameters, then return an ERROR indication as the status and (Invalid_d,
Invalid_Q) as the key pair; then exit the process without performing the remaining
steps.
3. L = len(n) + 64.
4. Obtain a string of L returned_bits using an RBG with a security strength of s bits
or more (see Section 5 in SP 800-133). If an ERROR indication is returned, thenreturn an ERROR indication as the status and (Invalid_d, Invalid_Q) as the key
pair; then exit the process without performing the remaining steps.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

5. Convert returned_bits to the (non-negative) integer c in the interval[0, 2L – 1] (see Appendix C.4).
6. d = (c mod (n – 1)) + 1.
7. Q = dG.
8. Return SUCCESS as the status and (d, Q) as the key pair.
Output: SUCCESS and (d, Q), oran ERROR indication and (Invalid_d, Invalid_Q).
5.6.1.2.2 Key Pair Generation by Testing Candidates

In this method, a random number is obtained and tested to determine whether or not it willproduce a value of d in the correct interval. If d would be outside the interval, another random
number is obtained (i.e., the process is iterated until an acceptable value of d is obtained).
The following process or its equivalent may be used to generate an ECC key pair.
Input:
1. (q, FR, a, b {, domain_parameter_seed}, G, n, h)
The ECC domain parameters that are used for this process. n is a prime
number, and G is a point on the elliptic curve (with the additive order n).
2. s

The maximum security strength to be supported by the key pair.

Output:
1. status The status returned from the key pair generation procedure. The statuswill indicate SUCCESS or an ERROR.
2.

(d, Q) The generated private and public keys. If an error is encountered during
the generation process, invalid values for d and Q should be returned, as
represented by Invalid_d and Invalid_Q in the following specification; forexample, Invalid_d and Invalid_Q could be a point that is not on theelliptic curve defined by the domain parameters. d is an integer in theinterval [1, n–1], and Q is an elliptic curve point.

31

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

Process:
1. If the domain parameters are not approved, then return an ERROR indication as
the status and (Invalid_d, Invalid_Q) as the key pair; then exit the process without
performing the remaining steps.
2. If s is not the maximum security strength that can be supported by the domain
parameters, then return an ERROR indication as the status and (Invalid_d,
Invalid_Q) as the key pair; then exit the process without performing the remaining
steps.
3. L = len(n).
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

4. Obtain a string of L returned_bits using an RBG with a security strength of s bits
or more (see Section 5 in SP 800-133). If an ERROR indication is returned, thenreturn an ERROR indication as the status and (Invalid_d, Invalid_Q) as the key
pair; then exit the process without performing the remaining steps.
5. Convert returned_bits to the (non-negative) integer c in the interval[0, 2L – 1] (see Appendix C.4).
6. If (c > n – 2), then go to step 4.
7. d = c + 1.
8. Q = dG.
9. Return SUCCESS as the status and (d, Q) as the key pair.
Output: SUCCESS and (d, Q), oran ERROR indication and (Invalid_d, Invalid_Q).
5.6.2 Required Assurances
To explain the assurance requirements associated with key-establishment key pairs, someterminology needs to be introduced. The owner of a static key pair is defined as the entitythat is authorized to use the private key that corresponds to the public key; this is independentof whether or not the owner generated the key pair. The recipient of a static public key isdefined as the entity that is participating in a key-establishment transaction with the ownerand obtains the key before or during the current transaction. The owner of an ephemeral
public key is the entity that generated the key as part of a key-establishment transaction. The
recipient of an ephemeral public key is the entity that receives that public key during a keyestablishment transaction with its owner.
Secure key establishment depends upon the use of valid key-establishment keys. Prior to
obtaining the assurances described in this section, the owner of a key pair and the recipientof the public key of that key pair shall obtain assurance of the validity of the associateddomain parameters (see Section 5.5.2).
The security of key-agreement schemes also depends on limiting knowledge of the private
keys to those who have been authorized to use them (i.e., their respective owners) and to atrusted third party if that party generated them. In addition to preventing unauthorized entities

32

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

from gaining access to private keys, it is also important that owners have access to theirprivate keys.
Note that as time passes, an owner may lose possession of the correct value of the private
key component of their key pair, either by choice or due to an error; for this reason, current
assurance of possession of a static private key can be of value for some applications, andrenewing assurance of possession may be necessary. See Section 5.6.2.2.3.2 for techniquesthat the recipient of a static public key can use to directly obtain more current assurance ofthe owner’s possession of the corresponding private key.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Prior to or during a key-establishment transaction, the participants in the transaction (i.e.,
parties U and V) shall obtain the appropriate assurances about the key pairs used during thattransaction. The types of assurance that may be sought by one or both of the parties (U and/orV) concerning the components of a key pair (i.e., the private key and public key) are
discussed in Sections 5.6.2.1 and 5.6.2.2. The methods that will be specified toprovide/obtain these assurances presuppose the validity of the domain parameters associatedwith the key pair (see Section 5.5).
The following sections include tables that summarize the types of assurance that are requiredby the parties to a key-establishment transaction. Table 2 in Section 5.6.2.1 summarizes
assurances that a key-pair owner may want to renew periodically. The shaded table entries
indicate a type of key pair (static or ephemeral) and a type of assurance that might be soughtfor such a key pair. The unshaded table entries indicate who can perform the actions
necessary to obtain the assurance.
5.6.2.1 Assurances Required by the Key Pair Owner
Prior to the use of a static or ephemeral key pair in a key-establishment transaction, the keypair owner shall confirm the validity of the key pair by obtaining the following assurances:•

Assurance of correct generation – assurance that the key pair was generated as
specified in Section 5.6.1 (see Section 5.6.2.1.1 for the methods for obtaining thisassurance).

•

Assurance of private-key validity – assurance that the private key is an integer in thecorrect interval, as determined by the domain parameters (see Section 5.6.2.1.2 forthe methods for obtaining this assurance).

•

Assurance of public-key validity – assurance that the public key has the correct
representation for a non-identity element of the correct cryptographic subgroup, as
uniquely determined by the domain parameters (see Section 5.6.2.1.3 for the methods
for obtaining this assurance).

•

Assurance of pair-wise consistency – assurance that the private key and public key
have the correct mathematical relationship to each other (see Section 5.6.2.1.4 for the
methods for obtaining this assurance).

Table 2 indicates the assurances to be obtained by the owner of a key pair for both static andephemeral keys, identifies who can perform the actions necessary for the owner to obtain

33

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptographyeach assurance, and indicates the sections of this document where further information isprovided.
Table 2: Initial assurances required by the key-pair owner
Key-pairtype
StaticCorrect
generation
Ownera or
TTPb

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Ephemeral
a
b
c
d
e
f

OwneraTypes of assurance
Private-key Public-key
validation
validation
OwnercOwnerd or
TTPe
OwnercOwnerdPair-wise
consistency
OwnerfOwnerfSee Section 5.6.2.1.1, method a.
See Section 5.6.2.1.1, method b
See Section 5.6.2.1.2
See Section 5.6.2.1.3, methods a and b.
See Section 5.6.2.1.3, method c.
See Section 5.6.2.1.4.

A static key-pair owner may optionally renew certain assurances regarding its key pair at any
time. Table 3 indicates which of the assurances obtained by the owner of a static key paircan be renewed and indicates the sections of this document where further information isprovided. Note that for ephemeral key pairs, only initial assurances are required; renewed
assurance for ephemeral key pairs is not applicable, since ephemeral key pairs are shortlived. Also, note that assurance of the correct generation of a static key pair is not renewablesince, after the fact, it is not feasible to verify that its private component was randomly
selected.
Table 3: Optional renewal of assurances by the key-pair owner
Key-pairtype
Statica.
b.
c.

Correct
generation
Infeasible

Types of assurance
Private-key Public-key
validation
validation
OwneraOwnerbPair-wise
consistency
OwnercSee Section 5.6.2.1.2.
See Section 5.6.2.1.3.
See Section 5.6.2.1.4.

Note that the methods used to obtain the required assurances are not necessarily independent.
For example, the key-pair owner may employ a key-generation routine that is consistent withthe criteria of Section 5.6.1 and also incorporates the actions required to provide (initial)
assurance of the validity and consistency of the private and public components of theresulting key pair.
As part of the proper implementation of this Recommendation, system users and/or agentstrusted to act on their behalf should determine which of the methods above meet theirsecurity requirements. The application tasked with performing key establishment on behalfof a party should determine whether to proceed with a key-establishment transaction, based
upon the perceived adequacy of the method(s) used to obtain the above assurances.
34

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

5.6.2.1.1 Owner Assurance of Correct Generation

Prior to the use of a key pair in a key-establishment transaction, the owner of a static or
ephemeral key-establishment key pair shall obtain an initial assurance that the key pair has
been correctly formed (in a manner that is consistent with the criteria of Section 5.6.1) using
one of the following methods:
a. For both a static and ephemeral key pair: The owner generates the key pair as
specified in Section 5.6, orThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

b. For a static key pair (only): A trusted third party (TTP) (trusted by the owner and any
recipient of the public key) generates the key pair as specified in Section 5.6.1 andprovides it to the owner. Note that, in this case, the TTP needs to be trusted by boththe owner and any public-key recipient to generate the key pair as specified in Section
5.6.1 and not to use the owner’s private key to masquerade as the owner. This method
is not appropriate for ephemeral key pairs, since the owner generates ephemeral keys.
5.6.2.1.2 Owner Assurance of Private-Key Validity

Prior to the use of a key pair in a key-establishment transaction, the owner of a static or
ephemeral key-establishment key pair shall obtain an initial assurance that the private key isan integer in the correct interval, which depends on the type of domain parameters that areused to generate key pairs.
•

When FFC domain parameters (p, q, g{, SEED, counter}) are used that conform to a
FIPS 186-type FFC parameter-size set from Table 1, private keys are in the interval[1, q – 1].

•

When an approved safe-prime group is used (see Section 5.5.1.1), and thecorresponding FFC domain parameters are (p, q = (p – 1)/2, g = 2), the private keys
are in the interval [1, M – 1], where M = min(2N, q), and N is the agreed-upon(maximum) bit length, satisfying 2s  N  len(q), where s is the maximum security
strength that can be supported by the safe-prime group, as specified in Appendix D.

•

When an approved elliptic-curve group is used, and the corresponding ECC domain
parameters are (q, FR, a, b{, SEED}, G, n, h), the private keys are in the interval [1,n – 1].

The owner of a static or ephemeral key-establishment key pair shall obtain an initialassurance that the private key is an integer in the correct interval by using one of thefollowing methods:
a. For both a static and ephemeral key pair: The owner generates the key pair as
specified in Section 5.6.1, orb. For a static key pair (only): After receiving a static key pair from a trusted third party(trusted by the owner), the owner performs a separate check to determine that theprivate key is in the correct interval. (While an entity can accept ownership of a static
key pair that was generated by a TTP, an ephemeral key pair shall only be generated
by its owner.)

35

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

To renew this assurance for a static key pair (if desired), the owner shall perform a separate
check to determine that the private key is in the correct interval as determined by the domain
parameters.
5.6.2.1.3 Owner Assurance of Public-Key Validity

Prior to a key-establishment transaction, the owner of a key pair shall obtain an initialassurance that the public key has the expected representation for a non-identity element of
the correct cryptographic subgroup, as determined by the domain parameters, using one of
the following methods:

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

a. For either a static key pair or an ephemeral key pair: The owner generates the key
pair as specified in Section 5.6.1 and performs a full public-key validation or anequivalent procedure as part of its generation process (see Section 5.6.2.3.1 for FFC,
and Section 5.6.2.3.3 for ECC); orb. For either a static key pair or an ephemeral key pair: The owner performs a full
public-key validation as a separate process from the key-pair generation process (seeSections 5.6.2.3.1 and 5.6.2.3.3) (either the owner or a TTP could have generated astatic key pair; only the owner can generate an ephemeral key pair); orc. For a static key pair (only): A trusted third party (TTP) (trusted by the owner)
performs a full public-key validation (see Sections 5.6.2.3.1 and 5.6.2.3.3) andprovides the validation result to the owner. This TTP could, for example, be a binding
authority (see Section 4.1) and/or a TTP that generated the key pair (see method b in
Section 5.6.2.1.1). In the case of TTP generation, the TTP shall either employ a keygeneration routine that performs a full public-key validation (or an equivalent
procedure) as part of its key-pair generation process, or perform a full public-key
validation as a separate process, following its key-pair generation process.
To renew this assurance for a static public key (if desired), the owner shall perform a
successful full public-key validation (see Section 5.6.2.3.1 for FFC, and Section 5.6.2.3.3 for
ECC). Note that renewed assurance of validity for an ephemeral public key is not applicable,
since ephemeral key pairs are short-lived.
5.6.2.1.4 Owner Assurance of Pair-wise Consistency

Prior to a key-establishment transaction, the owner of a key pair shall obtain an initialassurance that the private key and public key have the correct mathematical relationship toeach other by using one of the following methods:
a. For either a static key pair or an ephemeral key pair: The owner generates the key
pair as specified in Section 5.6.1, orb. For a static key pair (only): Subsequent to the generation of a static key pair by theowner or a trusted third party as specified in Section 5.6.1, the owner performs oneof the following consistency tests (as appropriate for the FFC or ECC domain
parameters used during the generation process).
•

For an FFC key pair (x, y): Use the private key, x, along with the generator g andprime modulus p included in the domain parameters associated with the key pair36

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

to compute gx mod p. Compare the result to the public key, y. If gx mod p is notequal to y, then the pair-wise consistency test fails.
•

For an ECC key pair (d, Q): Use the private key, d, along with the generator G
and other domain parameters associated with the key pair, to compute dG(according to the rules of elliptic-curve arithmetic). Compare the result to the
public key, Q. If dG is not equal to Q, then the pair-wise consistency test fails.

The static public key shall be successfully recomputed from the private key and thedomain parameters to obtain assurance (via method b) that the private and public keys
are consistent. If this pair-wise consistency test fails, the tested key pair shall not be
used.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

To renew assurance of pair-wise consistency for a static key pair (if desired), method b shallbe employed by the owner. Note that renewed assurance for ephemeral key pairs is notapplicable, since ephemeral key pairs are short-lived.
5.6.2.1.5 Owner Assurance of Possession of the Private Key

Prior to a key-establishment transaction, the owner of a key pair shall obtain an initialassurance of possession of the private key using one of the following methods:
a. For either a static key pair or an ephemeral key pair: The owner generates the key pair as
specified in Section 5.6.1, orb. For a static key pair (only): When a trusted third party (trusted by the owner) generates astatic key pair and provides it to the owner, the owner performs the appropriate pair-wise
consistency test in method b of Section 5.6.2.1.4; if the pair-wise consistency test fails,
the tested key pair shall not be used.
To renew this assurance for a static private key (if desired), the appropriate pair-wise
consistency tests in method b of Section 5.6.2.1.4 shall be employed by the owner. Note that
renewed assurance of the possession of an ephemeral private key is not applicable, sinceephemeral key pairs are short-lived.
5.6.2.2 Assurances Required by a Public Key Recipient
To successfully employ any of the schemes specified in this Recommendation, eachparticipant in a key-establishment transaction must receive at least one public key owned by
the other participant. The public key(s) may be received during the transaction (which isusually the case for an ephemeral public key) or prior to the transaction (as is sometimes thecase for a static public key). Regardless of the timing, a transaction participant is said to be
acting as a “public-key recipient” when it receives the other participant's public key(s). Notethat besides the participants (i.e., party U and party V), a binding authority (e.g., a CA) may
be a public key recipient (e.g., when obtaining assurance of possession).
Prior to or during a key-establishment transaction, the recipient of a public key shall obtainassurance of public-key validity and/or private-key possession as required below:•

Assurance of public-key validity – assurance that the public key of the other party(i.e., the claimed owner of the public key) has the (unique) correct representation fora non-identity element of the correct cryptographic subgroup, as determined by the37

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

domain parameters. Recipients of static public keys are required to obtain thisassurance (see Section 5.6.2.2.1). Recipients of ephemeral public keys are also
required to obtain this assurance.
•

Assurance of private-key possession – assurance that the claimed owner of a public
key-establishment key (i.e., the other party) actually has the (correct) private key
associated with that public key. Recipients of static public keys are required to obtain
this assurance (see Section 5.6.2.2.3). Recipients of ephemeral public keys areencouraged (but not required) to obtain this assurance; (optional) methods for
obtaining this assurance are discussed in Section 5.6.2.2.4.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Table 4 summarizes the assurances required by a public-key recipient for both the static andephemeral public keys of the other party, identifying the party that may perform the actions
necessary for the recipient to obtain the assurance and indicating the sections in thisdocument where further information is provided.
Table 4: Assurances required by a public-key recipientType of assurance
Key-pairtype

Public-key
validation

Private-key
possession

StaticRecipienta or TTPb

Recipientd or TTPe

Recipientc

Not Requiredf

Ephemeral
a
b
c
d.
e.
f

See Section 5.6.2.2.1, method 1.
See Section 5.6.2.2.1, method 2.
See Section 5.6.2.2.2.
See Section 5.6.2.2.3.2.
See Section 5.6.2.2.3.1.
However, see Section 5.6.2.2.4.

As part of the proper implementation of this Recommendation, system users and/or agentstrusted to act on their behalf should determine which of the indicated methods for obtaining
the required (and/or desired) assurances meet their security requirements. The application
tasked with performing key establishment on behalf of the recipient should determine
whether to proceed with a key-establishment transaction, based upon the perceived adequacyof the method(s) used to obtain the assurances described above.
Once the necessary steps have been taken to provide the recipient of a static public key withassurance of its validity, the assurance obtained by the recipient may endure for a protracted
period without the need to reconfirm the validity of that public key. The same may be trueof assurance provided to the recipient that the owner of the static public key possesses thecorresponding static private key. This could be the case, for example, when the source of theassurance is a trusted CA whose (valid) signature on a certificate containing the static public
key indicates to the recipient that the arithmetic validity of the static public key has been
confirmed by the CA and that the owner’s possession of the corresponding static private key
has been established to the CA’s satisfaction. Alternatively, a party could maintain a record
38

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography(i.e., an integrity-protected record) of previously received static public keys whose validity
was confirmed and/or whose owners have provided assurance of private-key possession.
On the other hand, the recipient of a static public key may choose to obtain renewed
assurance of its validity and/or choose to obtain renewed assurance that the owner of thestatic public key (i.e., the other party) possesses the corresponding static private key.
Deciding how often (if at all) to seek renewed assurance is a determination that should bemade by the recipient (or an agent trusted to act on the recipient’s behalf), based on therecipient’s security needs.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Renewed assurance of the validity of a received ephemeral public key and renewed assurance
that the other party is in possession of the corresponding ephemeral private key are notaddressed in this Recommendation, since ephemeral key pairs are short-lived.
5.6.2.2.1 Recipient Assurance of Static Public-Key Validity

The recipient of another party’s static public key shall obtain assurance of the validity of thatpublic key in one or more of the following ways:
1. The recipient performs a successful full public-key validation of the received public key(see Sections 5.6.2.3.1 for FFC domain parameters and Section 5.6.2.3.3 for ECC domain
parameters).
2. The recipient receives assurance that a trusted third party (trusted by the recipient) has
performed a successful full public-key validation of the received public key (see Sections
5.6.2.3.1 and 5.6.2.3.3). This TTP could, for example, be a binding authority, such as a
CA (see Section 4.1).
5.6.2.2.2 Recipient Assurance of Ephemeral Public-Key Validity

The recipient of another party’s ephemeral public key shall obtain assurance of its validity
by using one of the following methods:
1.

When an approved FFC safe-prime group or an approved elliptic curve group is
used by the key-establishment scheme:•

The recipient performs a successful partial public-key validation on the received
public key (see Section 5.6.2.3.2 for FFC domain parameters and Section
5.6.2.3.4 for ECC domain parameters)(As part of the proper implementation of this Recommendation, system users
and/or agents trusted to act on their behalf should determine whether a partial
validation of ephemeral public keys is sufficient to meet their security
requirements. If it is determined that partial public-key validation is insufficient,then full public-key validation shall be performed.)•

The recipient performs a successful full public-key validation on the received
public key (see Section 5.6.2.3.1 for FFC domain parameters and Section
5.6.2.3.3 for ECC domain parameters).

39

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

2. When FIPS 186-type FFC domain parameters are used in the key-establishment
scheme: The recipient performs a successful full public-key validation on thereceived public key (see Section 5.6.2.3.1 for FFC domain parameters).
5.6.2.2.3 Recipient Assurance of the Owner’s Possession of a Static Private Key

The recipient of another party’s static public key shall obtain an initial assurance that theother party (i.e., the claimed owner of the public key) possesses the associated private key,either prior to or concurrently with performing a key-agreement transaction with that otherparty. Assurance of the validity of the corresponding public key shall be obtained prior to
obtaining this assurance (unless the assurance of public-key validity and assurance of privatekey possession are obtained simultaneously from a trusted third party).
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

As part of the proper implementation of this Recommendation, system users and/or agentstrusted to act on their behalf should determine which of the methods for obtaining assuranceof possession meet their security requirements. The application tasked with performing key
establishment on behalf of a party should determine whether to proceed with a keyestablishment transaction, based upon the perceived adequacy of the method(s) used. Suchknowledge may be explicitly provided to the application in some manner, or may be
implicitly provided by the operation of the application itself.
A binding authority can be used to bind the key-pair owner’s identifier to his static public
key. In this case, at the time of binding an owner’s identifier to his static public key, thebinding authority (i.e., a trusted third party, such as a CA) shall obtain assurance that theowner is in possession of the correct static private key. This assurance shall either beobtained using one of the methods specified in Section 5.6.2.2.3.2 (e.g., with the binding
authority acting as the public-key recipient) or (only if using the FIPS 186-type domain
parameters or the approved ECC domain parameters) by using an approved alternative (seeSP 800-57, Sections 5.2 and 8.1.5.1.1.2). Note that the use of the signature-basedalternative described in SP 800-57 is not approved for the safe-prime domain
parameters.
Recipients not acting in the role of a binding authority shall obtain this assurance – either
through a trusted third party (see Section 5.6.2.2.3.1) or directly from the owner (i.e., theother party) (see Section 5.6.2.2.3.2) before using the derived keying material for purposes
beyond those required during the key-agreement transaction itself. If the recipient chooses
to obtain this assurance directly from the other party (i.e., the claimed owner of that publickey), then to comply with this Recommendation, the recipient shall use one of the methods
specified in Section 5.6.2.2.3.2.
5.6.2.2.3.1 Recipient Obtains Assurance from a Trusted Third Party

The recipient of a static public key may receive assurance that its owner (i.e., the other party
in the key-agreement transaction) is in possession of the correct static private key from atrusted third party (trusted by the recipient) either before or during a key-agreementtransaction that makes use of that static public key. The methods used by a third party trusted
by the recipient to obtain that assurance are beyond the scope of this Recommendation(however, see the discussion in Section 5.6.2.2.3 above).

40

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

5.6.2.2.3.2 Recipient Obtains Assurance Directly from the Claimed Owner (i.e., the Other
Party)

When two parties engage in a key-agreement transaction, there is (at least) an implicit claimof ownership made whenever a static public key is provided on behalf of a given party. Thatparty is considered to be a claimed owner of the corresponding static key pair – as opposed
to being a true owner – until adequate assurance can be obtained that the party is actually theone authorized to use the static private key. The claimed owner can provide such assurance
by demonstrating its knowledge of that private key.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

If all the following conditions are met during a key-agreement transaction that incorporates
key confirmation as specified in this Recommendation, then while establishing keying
material, the recipient of a static public key may be able to directly obtain (initial or renewed)
assurance of the claimed owner’s (i.e., the other party’s) current possession of thecorresponding static private key:
1. The recipient of the static public key contributes an ephemeral public key to the keyagreement process, one that is intended to be arithmetically combined with theclaimed owner’s (i.e., the other party’s) static private key in computations performedby the claimed owner. (If an appropriate key-agreement scheme is employed, theclaimed owner will be challenged to demonstrate current knowledge of his staticprivate key by successfully performing those computations during the transaction.)
2. The recipient of the static public key is also a key-confirmation recipient, with theclaimed owner (i.e., other party) serving as the key-confirmation provider. (Bysuccessfully providing key confirmation, the claimed owner can demonstrateownership of the received static public key and current knowledge of thecorresponding static private key.)
There are several key-agreement schemes specified in this Recommendation that can be usedwhile satisfying both of the conditions above. To claim conformance with thisRecommendation, the key-agreement transaction during which the recipient of a static public
key seeks to obtain assurance of its owner’s current possession of the corresponding staticprivate key shall employ one of the following approved key-agreement schemes,
incorporating key confirmation as specified in the indicated sections, with the recipient of thatstatic public key acting as party U and serving as a key-confirmation recipient:•

dhHybridOneFlow (see Section 6.2.1.1, and either Section 6.2.1.5.2 or Section
6.2.1.5.3),•(Cofactor) One-Pass Unified Model (see Section 6.2.1.2, and either Section 6.2.1.5.2
or Section 6.2.1.5.3),•

MQV1 (see Sections 6.2.1.3, and either Section 6.2.1.5.2 or Section 6.2.1.5.3),•

One-Pass MQV (see Section 6.2.1.4, and either Section 6.2.1.5.2 or Section
6.2.1.5.3),•

dhOneFlow (see Sections 6.2.2.1 and 6.2.2.3.1), or•(Cofactor) One-Pass Diffie-Hellman (see Sections 6.2.2.2 and 6.2.2.3.1).
41

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

5.6.2.2.4 Recipient Assurance of the Owner’s Possession of an Ephemeral Private
KeyThis Recommendation does not require the recipient of an ephemeral public key to obtainassurance of the possession of the corresponding ephemeral private key by its claimed owner(i.e., the other participant in a key-establishment transaction). However, such assurance may
be desired by the recipient, insisted upon by the recipient’s organization, and/or required by
an application. Assurance of the validity of the ephemeral public key shall be obtained prior
to obtaining assurance of possession of the private key.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Ephemeral key pairs are generated by their owner when needed, and their private components
are destroyed shortly thereafter (see Section 5.6.3.3 for details). Thus, the opportunity for therecipient of an ephemeral public key to obtain assurance that its claimed owner is inpossession of the corresponding ephemeral private key is limited to the (single) keyestablishment transaction during which it was received.
If all the following conditions are met during a key-agreement transaction that incorporates
key confirmation as specified in this Recommendation, then in the course of establishingkeying material, the recipient of an ephemeral public key may be able to obtain assurance
that the other participant (i.e., the claimed owner of that ephemeral public key) is inpossession of the corresponding ephemeral private key:
1. The recipient of the ephemeral public key also receives a static public key that ispresumed to be owned by the other party and is used in the key-agreementtransaction. (Therefore, the other party is the claimed owner of both the received
static public key and the received ephemeral public key.)
2. The recipient of the static and ephemeral public keys contributes its own (distinct)
ephemeral public key to the key-agreement process, one that is intended to bearithmetically combined with the private key corresponding to the received
ephemeral public key in computations performed by the claimed owner of thereceived static and ephemeral public keys. (If an appropriate key-agreement scheme
is employed, the claimed owner of the received public keys will be challenged todemonstrate current knowledge of his ephemeral private key by successfully
performing those computations during the transaction.)
3. The recipient of the static and ephemeral public keys is also a key confirmation
recipient, with the claimed owner of the received public keys serving as the keyconfirmation provider. (By successfully providing key confirmation, the claimed
owner of the received public keys can demonstrate that he is the owner of the received
static public key and that he knows the ephemeral private key corresponding to thereceived ephemeral public key.)
There are a limited number of key-agreement schemes specified in this Recommendationthat can be used while satisfying all three of the conditions above. To claim conformancewith this Recommendation, the key-agreement transaction during which the recipient ofan ephemeral public key seeks to obtain assurance of the claimed owner’s possession of
the corresponding ephemeral private key shall employ one of the following approved
key-agreement schemes, incorporating key confirmation as specified in the indicated42

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

sections, with the recipient of the ephemeral public key serving as a key-confirmation
recipient:•

dhHybrid1 (see Section 6.1.1.1 and Section 6.1.1.5) or•(Cofactor) Full Unified Model (see Section 6.1.1.2 and Section 6.1.1.5).

Note: If key confirmation is provided in both directions in a key-agreement transaction
employing one of the schemes above, then each party can obtain assurance of the otherparty’s possession of their ephemeral private key.
5.6.2.3 Public Key Validation Routines
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Public-key validation refers to the process of checking the arithmetic properties of acandidate public key. Both full and partial validation routines are provided for public keys
that are associated with either FFC or ECC domain parameters. Public-key validation does
not require knowledge of the associated private key and so may be done at any time byanyone. However, these routines assume a prior validation of the domain parameters
5.6.2.3.1 FFC Full Public-Key Validation Routine

FFC full public-key validation refers to the process of checking the arithmetic properties ofa candidate FFC public key to ensure that it has the expected representation and is in thecorrect subgroup of the multiplicative group of the finite field specified by the associatedFFC domain parameters.
This routine shall be used when assurance of full public-key validity is required (or desired)for a static or ephemeral FFC public key.
Input:
1. (p, q, g{, SEED, counter}): A valid set of FFC domain parameters, and
2. y: A candidate FFC public key.
Process:
1. Verify that 2  y  p − 2.
Success at this stage ensures that y has the expected representation for a nonzero field
element (i.e., an integer in the interval [1, p – 1]) and that y is in the proper range fora properly generated public key.
2. Verify22 that 1 = yq mod p.
Success at this stage ensures that y has the correct order and thus, is a non-identity
element in the correct subgroup of GF(p)*.
Output: If any of the above verifications fail, immediately output an error indicator and exit
without further processing. Otherwise, output an indication of successful validation.
22

When the FFC domain parameters correspond to a safe-prime group, 1 = yq mod p if and only if y is a(nonzero) quadratic residue modulo p, which can be verified by computing the value of the Legendre symbolof y with respect to p.

43

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

5.6.2.3.2 FFC Partial Public-Key Validation Routine

FFC partial public-key validation refers to the process of performing only the first step of afull public-key validation, omitting the check that determines whether the candidate FFC
public key is in the correct subgroup.
This routine shall only be used with ephemeral FFC public keys generated using theapproved safe-prime groups when assurance of the partial validity of such keys is to beobtained as specified in Section 5.6.2.2.2.
Input:
1. (p, q = (p –1)/2, g = 2) A valid set of "safe" FFC domain parameters corresponding
to a safe-prime group (see Section 5.5.1.1), andThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

2. y: A candidate FFC public key.
Process:
Verify that 2  y  p − 2.
Success at this stage ensures that y has the expected representation for a nonzero field
element (i.e., an integer in the interval [1, p – 1]) and that y is in the proper range fora properly generated public key.
Output: If the above verification fails, output an error indicator. Otherwise, output anindication of successful validation.
5.6.2.3.3 ECC Full Public-Key Validation Routine

ECC full public-key validation refers to the process of checking all the arithmetic propertiesof a candidate ECC public key to ensure that it has the expected representation for a nonidentity element of the correct subgroup of the appropriate elliptic-curve group, as specified
by the associated ECC domain parameters.
This routine shall be used when assurance of full public-key validity is required (or desired)for a static or ephemeral ECC public key.
Input:
1. (q, FR, a, b{, SEED}, G, n, h): A valid set of ECC domain parameters, and
2. Q = (xQ, yQ ): A candidate ECC public key.
Process:
1. Verify that Q is not the identity element Ø.
Success at this stage ensures that Q is not the identity element of the elliptic-curvegroup (which would never be the value of a properly generated public key).
2. Verify that xQ and yQ are integers in the interval [0, p − 1] in the case that q is an odd
prime p, or that xQ and yQ are bit strings of length m bits in the case that q = 2m.
Success at this stage ensures that each coordinate of the public key has the expected
representation for an element in the underlying field, GF(q).
3. Verify that Q is on the curve. In particular,
44

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography•

If q is an odd prime p, verify that (yQ)2 = ((xQ)3 + axQ + b) mod p.

•

If q = 2m, verify that (yQ)2 + xQ yQ = (xQ)3 + a(xQ)2 + b in GF(2m), where thearithmetic is performed as dictated by the field representation parameter FR.

Success at this stage ensures that the public key is a point on the correct elliptic curve.
4. Compute nQ (using elliptic curve arithmetic), and verify that nQ = Ø.
Success at this stage ensures that the public key has the correct order. Along with thesuccessful verifications in the previous steps, this step ensures that the public key isin the correct elliptic-curve subgroup and is not the identity element.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Output: If any of the above verifications fail, immediately output an error indicator andexit without further processing. Otherwise, output an indication of successful validation.
5.6.2.3.4 ECC Partial Public-Key Validation Routine

ECC partial public-key validation refers to the process of checking some (but not all) of thearithmetic properties of a candidate ECC public key to ensure that it has the expected
representation for a non-identity element of the correct elliptic-curve group, as specified by
the associated ECC domain parameters. ECC partial public-key validation omits thevalidation of subgroup membership23, and therefore, is usually faster than ECC full publickey validation.
This routine shall only be used when assurance of partial public-key validity is acceptable
for an ephemeral ECC public key.
Input:
1. (q, FR, a, b{, SEED}, G, n, h): A valid set of ECC domain parameters, and
2. Q = (xQ, yQ): A candidate ECC public key.
Process:
1. Verify that Q is not the identity element Ø.
Success at this stage ensures that Q is not the identity element of the elliptic-curvegroup (which would never be the value of a properly generated public key).
2. Verify that xQ and yQ are integers in the interval [0, p − 1] in the case that q is an odd
prime p, or that xQ and yQ are bit strings of length m bits in the case that q = 2m.
Success at this stage ensures that each coordinate of the public key has the expected
representation for an element in the underlying field, GF(q).
3. Verify that Q is on the curve. In particular,•

23

If q is an odd prime p, verify that (yQ) 2 = ((xQ)3 + axQ + b) mod p.

In this Recommendation, co-factor multiplication is included in the ECC primitives for Diffie-Hellman and
MQV, which forces the computed group element into the appropriate subgroup.

45

NIST SP 800-56A Rev. 3•

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

If q = 2m, verify that (yQ)2 + xQ yQ = (xQ)3 + a(xQ)2 + b in GF(2m), where thearithmetic is performed as dictated by the field representation parameter FR.

Together with the successful verifications in the previous steps, success at this stageensures that the public key is a (finite) point on the correct elliptic curve.
(Note: Since its order is not verified, there is no check that the public key is in thecorrect elliptic curve subgroup. The cofactor multiplication employed by the ECC
primitives used to compute a shared secret is intended to compensate for thisomission.)
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Output: If any of the above verifications fail, immediately output an error indicator and exit
without further processing. Otherwise, output an indication of validation success.
5.6.3 Key Pair Management
5.6.3.1 Common Requirements on Static and Ephemeral Key Pairs
The following are requirements on both static and ephemeral FFC and ECC key pairs:
1. Each private/public key pair shall be correctly associated with its corresponding
specific set of domain parameters. A key pair shall not be used with more than one
set of domain parameters.
2. Each key pair shall be generated as specified in Section 5.6.1.
3. Private keys shall be protected from unauthorized access, disclosure, modificationand substitution.
4. Public keys shall be protected from unauthorized modification and substitution. This
is often accomplished for static public keys by using public-key certificates that havebeen signed by a Certification Authority (CA). Ephemeral public keys may beprotected during communication using digital signatures or other protocol-specificmethods.
5.6.3.2 Specific Requirements on Static Key Pairs
The additional specific requirements for static key pairs are as follows:
1. The owner of a static key pair shall confirm the validity of the key pair by obtaining
assurance of the correct generation of the key pair, private and public-key validity,
and pair-wise consistency. The owner shall know the methods used to provide/obtainthese assurances. See Section 5.6.2.1 for further details.
2. A recipient of a static public key shall be assured of the integrity and correct
association of (a) the public key, (b) the set of domain parameters for that key, and(c) an identifier for the entity that owns the key pair (that is, the party with whom therecipient intends to establish secret keying material). This assurance is often provided
by verifying a public-key certificate that was signed by a trusted third party (forexample, a CA), but may be provided by direct distribution of the keying material
46

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

from the owner, provided that the recipient trusts the owner to do this. See Section
4.1.
3. A recipient of a static public key shall obtain assurance of the validity of the public
key. This assurance may be provided, for example, through the use of a public-key
certificate if the CA obtains sufficient assurance of public-key validity as part of its
certification process. See Section 5.6.2.2.1.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

4. A recipient of a static public key shall have assurance of the owner’s possession of
the corresponding private key (see Section 5.6.2.2.3). The recipient shall know themethod used to provide assurance to the recipient of the owner’s possession of theprivate key. This assurance may be provided, for example, using a public-key
certificate if the CA obtains sufficient assurance of possession as part of its
certification process.
5. A static key pair may be used in more than one key-establishment scheme. However,
one static public/private key pair shall not be used for different purposes (forexample, a digital-signature key pair is not to be used for key establishment or viceversa; key-usage restrictions could be enforced by a CA when generating certificates)with the following possible exception for ECC and FIPS 186-type FFC domain
parameters: when requesting the (initial) certificate for a public static keyestablishment key, the key-establishment private key associated with the public key
may be used to sign the certificate request. See SP 800-57 on Key Usage for further
information. A key-establishment key pair generated using safe-prime domain
parameters shall not ever be used for the generation of a digital signature.
5.6.3.3 Specific Requirements on Ephemeral Key Pairs
The additional specific requirements on ephemeral key pairs are as follows:
1. An ephemeral private key shall be used in exactly one key-establishment transaction.
After its use, an ephemeral private key shall be destroyed as soon as possible. Until
the private key is destroyed, its confidentiality shall be protected. An ephemeral
private key shall not be backed up or archived.
2. An ephemeral key pair should be generated as close to its time of use as possible.
Ideally, an ephemeral key pair is generated just before the ephemeral public key istransmitted.
3. The owner of an ephemeral key pair shall confirm the validity of the key pair byobtaining assurance of correct generation, private- and public-key validity, and pairwise consistency. The owner shall know the methods used to provide/obtain theseassurances. These assurances can be obtained by the technique used by the owner togenerate the ephemeral key pair. See Section 5.6.2.1 for further details.
4. A recipient of an ephemeral public key shall have assurance of the full or partial
validity of the public key as specified in Section 5.6.2.2.2.
5. If a recipient of an ephemeral public key requires assurance that the claimed ownerof that public key has possession of the corresponding private key, then, to obtain
47

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptographythat assurance in compliance with this Recommendation, such assurance shall beobtained as specified in Section 5.6.2.2.4. Although other methods are sometimes
used to provide such assurance, this Recommendation makes no statement as to theiradequacy.
5.7

DLC Primitives

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

A primitive is a relatively simple operation that is defined to facilitate implementation in
hardware or in a software subroutine. Each key-establishment scheme shall use exactly one
DLC primitive. Each scheme in Section 6 shall use an appropriate primitive from thefollowing list:
1. The FFC DH primitive (see Section 5.7.1.1): This primitive shall be used by thedhHybrid1, dhEphem, dhHybridOneFlow, dhOneFlow and dhStatic schemes, which
are based on finite field cryptography and the Diffie-Hellman algorithm.
2. The ECC CDH primitive (called the Modified Diffie-Hellman primitive in ANS
X9.63; see Section 5.7.1.2 below): This primitive shall be used by the Full Unified
Model, Ephemeral Unified Model, One-Pass Unified Model, One-Pass DiffieHellman and Static Unified Model schemes, which are based on elliptic curve
cryptography and the Diffie-Hellman algorithm.
3. The FFC MQV primitive (see Section 5.7.2.1): This primitive shall be used by the
MQV2 and MQV1 schemes, which are based on finite field cryptography and the
MQV algorithm.
4. The ECC MQV primitive (see Section 5.7.2.3): This primitive shall be used by the
Full MQV and One-Pass MQV schemes, which are based on elliptic curve
cryptography and the MQV algorithm.
The shared secret output from these primitives shall be used as input to a key-derivation
method (see Section 5.8).
5.7.1 Diffie-Hellman Primitives
5.7.1.1 Finite Field Cryptography Diffie-Hellman (FFC DH) Primitive
A shared secret Z is computed using the domain parameters (p, q, g{, SEED, counter}), theother party’s public key and one’s own private key. This primitive is used in Section 6 by
the dhHybrid1, dhEphem, dhHybridOneFlow, dhOneFlow and dhStatic schemes. Assume
that the party performing the computation is party A, and the other party is party B. Note thatparty A could be either party U or party V.
Input:
1. (p, q, g{, SEED, counter}): Domain parameters,
2. xA : One’s own private key, and3. yB : The other party’s public key.
Process:48

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

1. z = y B A mod p .
x

2. If ((z ≤ 1) OR (z = p – 1)), destroy all intermediate values used in the attempted
computation of Z (including z), then output an error indicator, and exit this process
without further processing.
3. Else, convert z to Z using the integer-to-byte-string conversion routine defined inAppendix C.1.
4. Destroy the results of all intermediate calculations used in the computation of Z
(including z).
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

5. Output Z.
Output: The shared secret Z or an error indicator.
5.7.1.2 Elliptic Curve Cryptography Cofactor Diffie-Hellman (ECC CDH)
Primitive
A shared secret Z is computed using the domain parameters (q, FR, a, b{, SEED}, G, n, h),
the other party’s public key, and one’s own private key. This primitive is used in Section 6by the Full Unified Model, Ephemeral Unified Model, One-Pass Unified Model, One-Pass
Diffie-Hellman and Static Unified Model schemes. Assume that the party performing thecomputation is party A, and the other party is party B. Note that party A could be either party
U or party V.
Input:
1. (q, FR, a, b{, SEED}, G, n, h): Domain parameters,
2. dA : One’s own private key, and
3. QB : The other party’s public key.
Process:
1. Compute the point P = hdAQB.
2. If P = Ø, destroy all intermediate values used in the attempted computation of P, thenoutput an error indicator, and exit this process without further processing.
3. Else, set z = xP, where xP is the x-coordinate of P, and convert z to Z, using the fieldelement-to-byte string conversion routine defined in Appendix C.2.
4. Destroy the results of all intermediate calculations used in the computation of Z
(including P and z).
5. Output Z.
Output: The shared secret Z or an error indicator.

49

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

5.7.2 MQV Primitives
5.7.2.1

Finite Field Cryptography MQV (FFC MQV) Primitive

A shared secret Z is computed using the domain parameters (p, q, g{, SEED, pgenCounter}),the other party’s public keys and one’s own public and private keys. Assume that the party
performing the computation is party A, and the other party is party B. Note that party A could
be either party U or party V.
Input:
1. (p, q, g{, SEED, counter}): Domain parameters,
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

2. xA : One’s own static private key,
3. yB : The other party’s static public key,
4. rA : One’s own second private key,24
5. tA : One’s own second public key, and6. tB : The other party’s second public key.
Process:

1
1. w =  log 2 q  .
2
2. TA = (t A mod 2 w ) + 2 w .
3. S A = (rA + TA x A ) mod q .
4. TB = (t B mod 2 w ) + 2 w .
5. z = ((t B ( yBTB )) S A ) mod p .
6. If ((z ≤ 1) OR (z = p – 1)), destroy all intermediate values (including TA, SA, and TB)
used in the attempted computation of z, then output an error indicator, and exit thisprocess without further processing.
7. Else, convert z to Z using the integer-to-byte-string conversion routine defined inAppendix C.1.
8. Destroy the results of all intermediate calculations used in the computation of Z
(including TA, SA, TB, and z).
9. Output Z.
Output: The shared secret Z or an error indicator.
24

In the FFC MQV primitive, a second key may be either ephemeral or static, depending on which form of
the primitive is being used; see Sections 5.7.2.1.1 and 5.7.2.1.2.

50

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

5.7.2.1.1 MQV2 Form of the FFC MQV Primitive

This form of invoking the FFC MQV primitive is used in Section 6.1.1.3 by the MQV2
scheme. In this form, each party uses both a static key pair and an ephemeral key pair.
Assume that the party performing the computation is party A, and the other party is party B.
Note that party A could be either party U or party V.
In this form, one’s own second private and public keys (items 4 and 5 of the input list in
Section 5.7.2.1) are one’s own ephemeral private and public keys (rA and tA), and the otherparty’s second public key (item 6 in Section 5.7.2.1) is the other party’s ephemeral publickey (tB).
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

5.7.2.1.2 MQV1 Form of the FFC MQV Primitive

This form of invoking the FFC MQV primitive is used in Section 6.2.1.3 by the MQV1
scheme. In this form, party U uses a static key pair and an ephemeral key pair, but party V
uses only a static key pair. One-Pass MQV uses the MQV primitive with party V’s static key
pair as the second key pair (as party V has no ephemeral key pair).
Party U uses party V’s static public key for the other party’s second public key; that is, whenparty U uses the algorithm in Section 5.7.2.1, item 6 of the input list is party V’s static publickey (yB).
Party V uses his/her static private key for the second private key; that is, when party V uses
the algorithm in Section 5.7.2.1, item 4 of the input list is party V’s static private key xA, anditem 5 becomes his static public key (yA).
5.7.2.2 ECC MQV Associate Value Function
The associate value function is used by the ECC MQV family of key-agreement schemes tocompute an integer that is associated with an elliptic curve point. This Recommendation
defines avf(Q) to be the associate value function of a public key Q using the domain
parameters (q, FR, a, b{, SEED}, G, n, h).
Input:
1. (q, FR, a, b{, SEED}, G, n, h): Domain parameters, and
2. Q: A public key (that is, Q is a point in the subgroup of order n and not equal to theidentity element Ø).
Process:
1. Convert xQ to an integer xqi using the convention specified in Appendix C.3.
2. Calculate
xqm = xqi mod 2  f / 2 (where f = log 2 n ).
3. Calculate the associate value function
avf(Q) = xqm + 2  f / 2 . (See footnote25).
25Note that avf(Q) can be computed using only bit operations.

51

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

Output: avf(Q), the associate value of Q.
5.7.2.3 Elliptic Curve Cryptography MQV (ECC MQV) Primitive
The ECC MQV primitive is computed using the domain parameters (q, FR, a, b{, SEED},
G, n, h), the other party’s public keys, and one’s own public and private keys. Assume thatthe party performing the computation is party A, and the other party is party B. Note thatparty A could be either party U or party V.
Input:
1. (q, FR, a, b{, SEED}, G, n, h): Domain parameters,
2. ds,A : One’s own static private key,
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

3. Qs,B : The other party’s static public key,
4. de,A : One’s own second private key,26
5. Qe,A : One’s own second public key, and
6. Qe,B : The other party’s second public key.
Process:
1. implicitsigA = (de,A + avf(Qe,A)ds,A ) mod n.
2. P = h(implicitsigA)(Qe,B + avf(Qe,B)Qs,B).
3. If P = Ø, destroy all intermediate values used in the attempted computation of P, thenoutput an error indicator, and exit this process without further processing.
4. Else, set z = xP, where xP is the x-coordinate of P, and convert z to Z, using the fieldelement-to-byte string conversion routine defined in Appendix C.2.
5. Destroy the results of all intermediate calculations used in the computation of Z
(including P and z).
6. Output Z.
Output: The shared secret Z or an error indicator.
5.7.2.3.1 Full MQV Form of the ECC MQV Primitive

This form of invoking the ECC MQV primitive is used in Section 6.1.1.4 by the Full MQV
scheme. In this form, each party has both a static key pair and an ephemeral key pair. Assume
that the party performing the computation is party A, and the other party is party B. Note thatparty A could be either party U or party V.
In this form, one’s own second private and public keys (item 4 and 5 of the input list in
Section 5.7.2.3) are one’s own ephemeral private and public keys (de,A and Qe,A), and the otherparty’s second public key (item 6 of the input list in Section 5.7.2.3) is the other party’s
ephemeral public key (Qe,B).
26

In the ECC MQV primitive, a second key may be either ephemeral or static, depending on which form of
the primitive is being used; see Sections 5.7.2.3.1 and 5.7.2.3.2.

52

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

5.7.2.3.2 One-Pass Form of the ECC MQV Primitive

This form of invoking the ECC MQV primitive is used in Section 6.2.1.4 by the One-Pass
MQV scheme. In this form, party U has a static key pair and an ephemeral key pair, but party
V has only a static key pair. One-Pass MQV uses the MQV primitive with party V’s static
key pair as the second key pair (as party V has no ephemeral keys).
Party U uses party V’s static public key as the other party’s second public key. When party
U uses the algorithm in Section 5.7.2.3, item 6 of the input list is party V’s static public key(Qs,B).

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Party V uses his static private key as his second private key. When party V uses the algorithm
in Section 5.7.2.3, item 4 of the input list is V’s static private key ds,A, and item 5 is his static
public key (Qs,A).
5.8

Key-Derivation Methods for Key-Agreement Schemes

An approved key-derivation method shall be used to derive keying material from the sharedsecret, Z, that is computed during the execution of a key-agreement scheme specified in thisRecommendation. The shared secret shall be used only by an approved key-derivation
method (as specified in SP 800-56C) and shall not be used for any other purpose.
When employed during the execution of a key-agreement scheme as specified in thisRecommendation, the agreed-upon key-derivation method uses input that includes a freshly
computed shared secret Z, along with other information. The derived keying material shallbe computed in its entirety before outputting any portion of it, and (each copy of) Z shall betreated as a critical security parameter in a cryptographic module and destroyed immediately
following its use.
The output produced by a key-derivation method using input that includes the shared secretcomputed during the execution of any key-agreement scheme specified in thisRecommendation shall only be used as secret keying material – such as a symmetric key
used for data encryption or message integrity, a secret initialization vector, or, perhaps, a
key-derivation key that will be used to generate additional keying material (possibly using a
different process – see SP 800-10827). The derived keying material shall not be used as a key
stream for a stream cipher. Non-secret keying material (such as a non-secret initialization
vector) shall not be generated using a key-derivation method that includes the shared secret,Z, as input (this restriction applies to all one-step and two-step key-derivation methods).
5.8.1 Performing the Key Derivation
Approved methods for key derivation from a shared secret are specified in SP 800-56C28.
These methods can be accessed using the following call:
KDM(Z, OtherInput),
where

27

SP 800-108, Recommendation for Key Derivation Using Pseudorandom Functions.

28

SP 800-56C, Recommendation for Key Derivation Methods in Key Establishment Schemes.

53

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

1. Z is a byte string that represents the shared secret,
2. OtherInput consists of additional input information that may be required by a given
key-derivation method, for example:•

L − an integer that indicates the length (in bits) of the secret keying material to be
derived.

•salt − a byte string.

•IV – a bit string used as an initialization value.

•

FixedInfo – a bit sting of context-specific data (see Section 5.8.2).

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

See SP 800-56C for details concerning the appropriate form of OtherInput.
5.8.2 FixedInfo
The bit string FixedInfo should be used to ensure that the derived keying material isadequately “bound” to the context of the key-agreement transaction. Although other methods
may be used to bind keying material to the transaction context, this Recommendation makes
no statement as to the adequacy of these other methods. Failure to adequately bind thederived keying material to the transaction context could adversely affect the types ofassurance that can be provided by certain key-agreement schemes.
Context-specific information that may be appropriate for inclusion in FixedInfo:•

Public information about parties U and V, such as their identifiers.

•

The public keys contributed by each party to the key-agreement transaction. (In thecase of a static public key, one could include a certificate that contains the public
key.)

•

Other public and/or private information shared between parties U and V before or
during the transaction, such as nonces or pre-shared secrets.

•

An indication of the protocol or application employing the key-derivation method.

•

Protocol-related information, such as a label or session identifier.

•

Agreed-upon encodings (as bit strings) of the values of one or more of the otherparameters used as additional input to the KDM (e.g., L, salt, and/or IV).

•

An indication of the key-agreement scheme and/or key-derivation method used.

•

An indication of the domain parameters associated with the asymmetric key pairs
employed for key establishment.

•

An indication of other parameter or primitive choices (e.g., the agreed-uponhash/MAC algorithms, the bit lengths of any MAC tags used for key confirmation,etc.).

•

An indication of how the derived keying material should be parsed, including an
indication of which algorithm(s) will use the (parsed) keying material.

54

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

For rationale in support of including entity identifiers, scheme identifiers, and/or otherinformation in FixedInfo, see Appendix B.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

When FixedInfo is used, the meaning of each information item and each item’s position
within the FixedInfo bit string shall be specified. In addition, each item of information
included in FixedInfo shall be unambiguously represented. For example, each item of
information could take the form of a fixed-length bit string, or, if greater flexibility is needed,
an item of information could be represented in a Datalen || Data format, where Data is avariable-length string of zero or more (eight-bit) bytes, and Datalen is a fixed-length, bigendian counter that indicates the length (in bytes) of Data. These requirements can besatisfied, for example, by using ASN.1 DER encoding for FixedInfo, as specified in Section
5.8.2.1.2.
SP 800-56C specifies both one-step key-derivation methods (i.e., key-derivation functions)and two-step key-derivation methods (i.e., key-derivation procedures). The following
subsections discuss possibilities for the form and format of FixedInfo when it is used by those
approved key-derivation methods.
5.8.2.1 One-step Key Derivation
Recommended formats for FixedInfo when used by a one-step key-derivation method are
specified in Sections 5.8.2.1.1 and 5.8.2.1.2. One of those two formats should be used by aone-step key-derivation method specified in SP 800-56C when the auxiliary function
employed is H = hash.
When FixedInfo is included during the key-derivation process, and the recommended formats
are used, the included items of information shall be divided into (three, four, or five)
subfields as defined below.
AlgorithmID: A required non-null subfield that indicates how the derived keying material
will be parsed and for which algorithm(s) the derived secret keying material will be used.
For example, AlgorithmID might indicate that bits 1-112 are to be used as a 112-bit
HMAC key and that bits 113-240 are to be used as a 128-bit AES key.
PartyUInfo: A required non-null subfield containing public information about party U.
At a minimum, PartyUInfo shall include IDU, an identifier for party U, as a distinct itemof information. This subfield could also include information about the public key(s)contributed to the key-agreement transaction by party U. The nonce provided by party U
as required in a C(0e, 2s) scheme (see Section 6.3) shall be included in this subfield.
PartyVInfo: A required non-null subfield containing public information about party V.
At a minimum, PartyVInfo shall include IDV, an identifier for party V, as a distinct itemof information. This subfield could also include information about the public key(s)contributed to the key-agreement transaction by party V. The nonce provided by party V
when acting as a key-confirmation recipient in a C(1e, 2s) scheme or a C(0e, 2s) scheme
shall be included in this field (see Sections 6.2.1.5 and 6.3.3).
SuppPubInfo: An optional subfield that contains additional, mutually known public
information (e.g., L, the domain parameters associated with the keys used to derive theshared secret, an identifier for the particular key-agreement scheme that was used to form
55

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

Z, an indication of the protocol or application employing that scheme, a session identifier,etc.; this is particularly useful if these aspects of the key-agreement transaction can vary– see Appendix B for further discussion). While an implementation may be capable ofincluding this subfield, the subfield may be Null for a given transaction.
SuppPrivInfo: An optional subfield that contains additional, mutually known private
information (e.g., a shared symmetric key that has been communicated through a separate
channel or established by other means). While an implementation may be capable ofincluding this subfield, the subfield may be Null for a given transaction.
5.8.2.1.1 The Concatenation Format for FixedInfo
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

This section specifies the concatenation format for FixedInfo. This format has been designed
to provide a simple means of binding the derived keying material to the context of the keyagreement transaction, independent of other actions taken by the relying application. Note:
When the one-step key-derivation method specified in SP 800-56C is used with H = hash as
the auxiliary function and this concatenation format for FixedInfo, the resulting keyderivation method is the Concatenation Key-Derivation Function specified in the original
version of SP 800-56A.
For this format, FixedInfo is a bit string equal to the following concatenation:
AlgorithmID || PartyUInfo || PartyVInfo {|| SuppPubInfo }{|| SuppPrivInfo },where the five subfields are bit strings comprised of items of information as described in
Section 5.8.2.
Each of the three required subfields AlgorithmID, PartyUInfo, and PartyVInfo shall be theconcatenation of a pre-determined sequence of substrings in which each substring represents
a distinct item of information. Each such substring shall have one of these two formats: either
it is a fixed-length bit string, or it has the form Datalen || Data – where Data is a variablelength string of zero or more (eight-bit) bytes, and Datalen is a fixed-length, big-endian
counter that indicates the length (in bytes) of Data. (In this variable-length format, a null
string of data shall be represented by a zero value for Datalen, indicating the absence offollowing data.) A protocol using this format for FixedInfo shall specify the number,ordering and meaning of the information-bearing substrings that are included in each of thesubfields AlgorithmID, PartyUInfo, and PartyVInfo, and shall also specify which of the twoformats (fixed-length or variable-length) is used by each such substring to represent its
distinct item of information. The protocol shall specify the lengths for all fixed-length
quantities, including the Datalen counters.
Each of the optional subfields SuppPrivInfo and SuppPubInfo (when allowed by the protocol
employing the one-step key-derivation method) shall be the concatenation of a predetermined sequence of substrings representing additional items of information that may be
used during key derivation upon mutual agreement of parties U and V. Each substring
representing an item of information shall be of the form Datalen || Data, where Data is avariable-length string of zero or more (eight-bit) bytes and Datalen is a fixed-length, bigendian value that indicates the length (in bytes) of Data; the use of this form for the
information allows parties U and V to omit an information item without confusion about themeaning of the other information that is provided in the SuppPrivInfo or SuppPubInfo
56

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

subfield. The substrings representing items of information that parties U and V choose notto contribute are set equal to Null, and are represented in this variable-length format by
setting Datalen equal to zero. If a protocol allows the use of the SuppPrivInfo and/or
SuppPubInfo subfield(s), then the protocol shall specify the number, ordering and meaningof additional items of information that may be used in the allowed subfield(s) and shallspecify the fixed-length of the Datalen values.
5.8.2.1.2 The ASN.1 Format for FixedInfo

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

The ASN.1 format for FixedInfo provides an alternative means of binding the derived keying
material to the context of the key-agreement transaction, independent of other actions takenby the relying application. Note: When the one-step key-derivation method specified in SP
800-56C is used with H = hash as the auxiliary function and this ASN.1 format for FixedInfo,
the resulting key-derivation method is the ASN.1 Key-Derivation Function specified in theoriginal version of SP 800-56A.
For the ASN.1 format, FixedInfo is a bit string resulting from the ASN.1 DER encoding (seeISO/IEC 8825-1) of a data structure comprised of a sequence of three required subfields
AlgorithmID, PartyUInfo, and PartyVInfo, and, optionally, a SuppPubInfo subfield and/or a
SuppPrivInfo subfield – as described in Section 5.8.2. A protocol using this format for
FixedInfo shall specify the type, ordering and number of distinct items of information
included in each of the (three, four, or five) subfields employed.
5.8.2.2 Two-step Key-Derivation (Extraction-then-Expansion)
For the two-step key-derivation method specified in SP 800-56C, FixedInfo is a bit stringthat contains component data fields such as a Label, Context information, and [L]2, where:•

Label is a binary string that identifies the purpose of the derived keying material. The
encoding method for the label is defined in a larger context, for example, in a protocol
using the key-derivation method.

•

Context is a binary string containing information relating to the derived keying
material. Section 5.8.2 provides a list of context-specific information that may beappropriate for the inclusion in this string.

•[L]2 is a binary string that specifies the length (in bits) of the keying material to be
derived.

Different orderings of the component data fields of FixedInfo may be used, and one or more of
the data fields may be combined (or omitted under certain circumstances). See Section 5 in SP
800-56C, and Sections 5, 7.4, 7.5 and 7.6 in SP 800-108 for details

5.8.2.3 Other Formats for FixedInfo
Formats other than those provided in Sections 5.8.2.1 and 5.8.2.2 (e.g., those providing theitems of information in a different arrangement) may be used for FixedInfo, but contextspecific information should be included (see the discussion in Section 5.8.2). This
Recommendation makes no statement as to the adequacy of other formats.

57

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

5.9 Key Confirmation
The term key confirmation (KC) refers to actions taken to provide assurance to one party (thekey-confirmation recipient) that another party (the key-confirmation provider) is inpossession of a (supposedly) shared secret and/or confirm that the other party has the correct
version of keying material that was derived during a key-establishment transaction. (Correct,
that is, from the perspective of the key-confirmation recipient.) Such actions are said toprovide unilateral key confirmation when they provide this assurance to only one of theparticipants in the key-establishment transaction; the actions are said to provide bilateral key
confirmation when this assurance is provided to both participants (i.e., when unilateral key
confirmation is provided in both directions).
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Oftentimes, key confirmation is obtained (at least implicitly) by some means external to the
key-establishment scheme employed during a transaction (e.g., by using a symmetric key
that was established during the transaction to decrypt an encrypted message sent later by the
key-confirmation provider), but this is not always the case. In some circumstances, it may beappropriate to incorporate the exchange of explicit key-confirmation information as anintegral part of the key-establishment scheme itself. The inclusion of key confirmation may
enhance the security services that can be offered by a key-establishment scheme. For
example, when certain key-agreement schemes incorporate key confirmation (as describedin this Recommendation), they can be used to provide the recipient with assurance that theprovider is in possession of the private key corresponding to a particular public key, fromwhich the recipient may infer that the provider is the owner of that key pair (see Sections
5.6.2.2.3 and 5.6.2.2.4).
For key confirmation to comply with this Recommendation, key confirmation shall beincorporated into an approved key-establishment scheme as specified in Sections 5.9.1 and5.9.2 for keying material derived during the execution of a key-agreement scheme.
5.9.1 Unilateral Key Confirmation for Key-Agreement Schemes
As specified in this Recommendation, unilateral key confirmation occurs when one
participant in the execution of a key-agreement scheme (the key-confirmation “provider”)
demonstrates to the satisfaction of the other participant (the key-confirmation “recipient”)
that both the provider and the recipient have possession of the same secret MacKey.
MacKey is a symmetric key derived using the (shared) secret Z that was computed by eachparty during that particular execution of the key-agreement scheme (see Section 5.8 about
key-derivation methods). MacKey and certain context-specific MacData (see step 2 below)
are used by the provider as input to an approved MAC algorithm to obtain a MacTag that issent to the recipient. The recipient performs an independent computation of the MacTag. If
the MacTag value computed by the key-confirmation recipient matches the MacTag value
received from the key-confirmation provider, then key confirmation is successful. See
Section 5.2 for MacTag generation and verification, and Section 5.9.3 for a MacTag security
discussion.
Successful key confirmation provides assurance to the recipient that the same Z value has
been computed by both parties and that the two parties have used Z in the same way to deriveshared keying material.
58

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

Unilateral key confirmation is an optional feature that can be incorporated into any keyagreement scheme in which the key-confirmation provider is required to own a static keyestablishment key pair that is used in the key-establishment process. If the intended keyconfirmation recipient is not required to contribute an ephemeral public key to the keyestablishment process, then the recipient shall instead contribute a nonce that is used as partof the input to the key-derivation method employed by the scheme. Each party shall have an
identifier, chosen in accordance with the assumptions stated for the key-agreement scheme.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

To include unilateral key confirmation from a provider (who has a static key pair) to arecipient, the following steps shall be incorporated into the scheme. Additional details will
be provided for each scheme in the appropriate subsections of Section 6. In the discussionthat follows, the key-confirmation provider, P, may be either party U or party V, as long as
P has a static key pair. The key-confirmation recipient, R, is the other party.
1. If the recipient, R, is not required to generate an ephemeral key pair as part of the
key-agreement scheme, then R shall contribute a nonce to be used (in addition to theshared secret Z) as input to the key-derivation method employed by the scheme; that
nonce will also be used as part of the ephemeral data input to the MAC tag
computations performed during key conformation. See Section 5.4 for a discussionof the length and security strength required for the nonce.
2. The provider, P, computes
MacDataP = message_stringP || IDP || IDR || EphemDataP || EphemDataR {|| TextP}
where- message_stringP is a six byte string with a value of “KC_1_U” when party U isproviding the MacTag, or “KC_1_V” when party V is providing the MacTag.
(Note that these values will be changed for bilateral key confirmation, as specified
in Section 5.9.2.)- IDP is the identifier used to label the key-confirmation provider.
- IDR is the identifier used to label the key-confirmation recipient.
- EphemDataP and EphemDataR are ephemeral values (corresponding to ephemeral
public keys or nonces) contributed by the provider and recipient, respectively.
The ephemeral data is specified in the subsections of Section 6 that describe how
key confirmation can be incorporated into the particular schemes included in thisRecommendation.
o EphemDataP is Null only in the case that the provider has contributed neither
an ephemeral public key nor a nonce during the scheme. For example, in aC(1e, 2s) scheme with unilateral key confirmation from party V to party U as
introduced in Section 6.2.1.5.2, party V only contributes a static key pair; inthis case, EphemDataV can be Null.
o When EphemDatai, (where i is P or R) is an ephemeral public key, the public
key EphemPubKeyi is a byte string determined as follows:59

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

For FFC schemes, i’s ephemeral public key, ti, is converted from a field
element in GF(p) to a byte string by representing the field element as aninteger in the interval [2, p − 2], and then converting the integer to a byte
string as specified in Appendix C.1.
For ECC schemes, the coordinates of i’s ephemeral public key, Qe,i, areconverted from field elements to byte strings as specified in Appendix C.2
and concatenated (with the x coordinate first) to form a single byte string.
- TextP is an optional byte string that may be used during key confirmation andthat is known by both parties.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

The content of each of the components that are concatenated to form MacDataP shallbe precisely defined and unambiguously represented. A component’s content may be
represented, for example, as a fixed-length bit string or in the form Datalen || Data,
where Data is a variable-length string of zero or more (eight-bit) bytes, and Datalen
is a fixed-length, big-endian counter that indicates the length (in bytes) of Data.
These requirements could also be satisfied by using a specific ASN.1 DER encodingof each component. It is imperative that the provider and recipient have agreed upon
the content and format that will be used for each component of MacDataP.
3. After computing the shared secret Z and applying the key-derivation method to obtain
DerivedKeyingMaterial (see Section 5.8 and SP 800-56C), the provider uses agreedupon bit lengths to parse DerivedKeyingMaterial into two parts, MacKey and
KeyData, of the pre-agreed lengths:
MacKey || KeyData = DerivedKeyingMaterial.
4. Using an agreed-upon bit length for MacTagBits, the provider computes MacTagP(see Sections 5.2.1 and 5.9.3):
MacTagP = TMacTagBits[MAC (MacKey, MacDataP)],and sends it to the recipient.
5. The recipient forms MacDataP, determines MacKey, computes MacTagP in the samemanner as the provider, and then verifies that the computed MacTagP is equal to thevalue received from the provider. If the values are equal, then the recipient is assured
that the provider has derived the same value for MacKey and that the provider shares
the recipient’s value of MacDataP. The assurance of a shared value for MacKey
provides assurance to the recipient that the provider also shares the secret value (Z)from which MacKey and KeyData are derived. Thus, the recipient also has assurance
that the provider could compute KeyData correctly.
Both parties shall destroy the MacKey once it is no longer needed to provide or obtain key
confirmation.
If, during a key-agreement transaction, it happens that MacTagP cannot be verified by therecipient, then key confirmation has failed, and all of the derived keying material (MacKey
and KeyData) shall be destroyed by each participant. In particular, DerivedKeyingMaterial
shall not be revealed by either participant to any other party (not even to the other60

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

participant), and the derived keying material shall not be used for any further purpose. In thecase of a key-confirmation failure, the key-agreement transaction shall be discontinued.
Unilateral key confirmation may be added in either direction to any of the C(2e, 2s), C(1e,2s) and C(0e, 2s) schemes; it may also be added to the C(1e, 1s) schemes, but only whenparty V (the party contributing the static key pair) is the key-confirmation provider, and party
U is the key-confirmation recipient. See the relevant subsections of Section 6.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

5.9.2 Bilateral Key Confirmation for Key-Agreement Schemes
Bilateral key confirmation is an optional feature that can be incorporated into any keyagreement scheme in which each party is required to own a static key-establishment key pairthat is used in the key-establishment process. Bilateral key confirmation is accomplished by
performing unilateral key confirmation in both directions (with party U providing MacTagU
to recipient party V, and party V providing MacTagV to recipient party U) during the same
key-agreement transaction. If a party is not also required to contribute an ephemeral public
key to the key-establishment process, then that party shall instead contribute a nonce that isused as part of the input to the key-derivation method employed by the scheme; the nonce
will also be used as part of the ephemeral data input to the MAC tag computations performed
during key conformation. See Section 5.4 for a discussion of the length and security strength
required for the nonce. Each party shall have an identifier, chosen in accordance with theassumptions stated for the key-agreement scheme.
To include bilateral key confirmation, two instances of unilateral key confirmation (asspecified in Section 5.9.1, subject to the modifications listed below) shall be incorporated
into the scheme, once with party U as the key-confirmation provider (i.e., P = U and R = V)
and once with party V as the provider (i.e., P = V and R = U). Additional details will be
provided for each scheme in the appropriate subsections of Section 6.
In addition to setting P = U and R = V in one instance of the unilateral key-confirmation
procedure described in Section 5.9.1 and setting P = V and R = U in a second instance, thefollowing changes/clarifications apply when using the procedure for bilateral key
confirmation:
1. When computing MacTagU, the value of the six-byte message_stringU that forms theinitial segment of MacDataU is “KC_2_U”.
2. When computing MacTagV, the value of the six-byte message_stringV that forms theinitial segment of MacDataV is “KC_2_V”.
3. If used at all, the value of the (optional) byte string TextU used to form the final
segment of MacDataU can be different than the value of the (optional) byte string
TextV used to form the final segment of MacDataV, provided that both parties areaware of the value(s) used.
Bilateral key confirmation may be added to the C(2e, 2s), C(1e, 2s) and C(0e, 2s) schemes,
as specified in the relevant subsections of Section 6.

61

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

5.9.3 Selecting the MAC and Other Key-Confirmation Parameters
Key confirmation as specified in this Recommendation requires that a MacKey of an
appropriate length be generated as part of the derived keying material (see Section 5.9.1).
The MacKey is then used with a MAC algorithm to generate a MAC; the length of the MAC
output by the MAC algorithm is MacOutputBits. The MAC is subsequently used to form a
MAC tag (see Section 5.9.1 for the generation of the MAC and Section 5.2.1 for theformation of the MAC tag from the MAC).
Table 5 provides a list of approved MAC algorithms for key confirmation and the security
strengths that each can support, along with the corresponding value of MacOutputBits andpermissible MacKey lengths for each MAC algorithm.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Table 5: Approved MAC algorithms for key confirmation.

MAC Algorithm
HMAC_SHA-1
HMAC_SHA-224
HMAC_SHA-512/224
HMAC_SHA-256
HMAC_SHA-512/256
HMAC_SHA-384
HMAC_SHA-512
HMAC_SHA3-224
HMAC_SHA3-256
HMAC_SHA3-384
HMAC_SHA3-512
KMAC128
KMAC256
AES-128-CMAC
AES-192-CMAC
AES-256-CMAC*

MacOutputBits

160
224
224
256
256
384
512
224
256
384
512
 22040 – 1(see * below)
128
128
128

Permissable
MacKey Lengths( bits)s    512

 = 128
 = 192
 = 256

Supported Security
Strengths for Key
Confirmation(s bits)

112  s  256

112  s  128
112  s  256
112  s  128
112  s  192
112  s  256

Although KMAC128 and KMAC256 can accommodate values as large as 22040 − 1
for MacOutputBits, practical considerations dictate that the lengths oftransmitted MAC tags be limited to sizes that are more realistic and commensuratewith the actual performance/security requirements of the relying applications.

The MAC algorithm used to compute a key-confirmation MAC tag in compliance with thisRecommendation shall be selected from among the approved MAC algorithms capable ofsupporting a security strength s that is at least as large as the targeted security strength of the
key-establishment scheme (as indicated in Table 5 above).
Note that when an HMAC or KMAC algorithm is used for key confirmation as specified inthis Recommendation, MacKey lengths can be no greater than 512 bits (an upper bound thatis at least twice the maximum supported security strength). This upper bound is smaller than62

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

any of the upper bounds imposed in the HMAC or KMAC algorithm specifications, but issufficient for this application. In the case of HMAC, the 512-bit upper bound has theadvantage of being less than the input block length of whatever hash function is used in thealgorithm’s implementation. If MacKey were allowed to be longer than the input block
length, it would be hashed down to a string of length MacOutputBits during the HMAC
computation (see step 2 in Table 1 of FIPS 198); allowing MacKey to be longer than the
input block length would not be an efficient use of keying material.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

The length of the MAC tag for key confirmation also needs to be selected. Note that in manycases, the length of the MAC tag (MacTagBits) has been selected by the protocol in which
the key-establishment is conducted. MacTagBits shall be at least 64 bits, and its maximum
length shall be no more than the MacOutputBits for the MAC algorithm selected for key
confirmation. The 64-bit minimum for the MAC tag length assumes that the protocol imposesa limit on the number of retries for key confirmation.

63

NIST SP 800-56A Rev. 3

6.

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

Key Agreement Schemes

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

This Recommendation provides three categories of key-agreement schemes (see Table 6).
The classification of the categories is based on the number of ephemeral keys used by thetwo parties to the key-agreement process, parties U and V. In category C(ie), parties U andV have a total of i ephemeral key pairs. The first category, C(2e), consists of schemes
requiring the generation of ephemeral key pairs by both parties; a C(2e) scheme is suitable
for an interactive key-establishment protocol. The second category, C(1e), consists ofschemes requiring the generation of an ephemeral key pair by only one party; a C(1e) scheme
is suitable for a store-and-forward scenario, but may also be used in an interactive keyestablishment protocol. The third category, C(0e), consists of schemes that do not use
ephemeral keys.
Key confirmation may be added to many of these schemes to provide assurance that theparticipants share the same keying material; see Section 5.9 for details on key confirmation.
Each party should have such assurance. Although other methods are often used to provide
this assurance, this Recommendation makes no statement as to the adequacy of these othermethods.
Table 6: Key-agreement scheme categories.
Category

Comment

C(2e): Two ephemeral key pairs

Each party generates an ephemeral key pair.

C(1e): One ephemeral key pair

Only party U generates an ephemeral key pair.

C(0e): Zero ephemeral key pairs

No ephemeral keys are used.

Each category is comprised of one or more subcategories that are classified by the use ofstatic keys by the parties (see Table 7). In subcategory C(ie, js), parties U and V have a totalof i ephemeral key pairs and j static key pairs. The suitability for interactive or store-andforward protocols of each subcategory is discussed in Section 7.
Table 7: Key-agreement scheme subcategories.
CategoryC(2e): Two ephemeral key
pairs

SubcategoryC(2e, 2s): Each party generates an ephemeral key pair anduses a static key pair.
C(2e, 0s): Each party generates an ephemeral key pair; nostatic key pairs are used.

C(1e): One ephemeral key
pair

C(1e, 2s): Party U generates an ephemeral key pair and uses
a static key pair; party V uses only a static key pair.

64

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

Category

SubcategoryC(1e, 1s): Party U generates an ephemeral key pair, butuses no static key pair; party V uses only a static key pair.

C(0e): Zero ephemeral key
pairs

C(0e, 2s): Each party uses only a static key pair.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

The schemes may be further classified by whether they use finite field cryptography (FFC)or elliptic curve cryptography (ECC). A scheme may use either Diffie-Hellman or MQVprimitives (see Section 5.7). Thus, for example, notation C(2e, 2s, FFC DH) completelyclassifies the dhHybrid1 scheme of Section 6.1.1.1 as a scheme with two ephemeral keys andtwo static keys that uses finite field cryptography and a Diffie-Hellman primitive (see Table
8). The names of these schemes are taken from ANS X9.42 and ANS X9.63.
Table 8: Key-agreement schemes.
Category Subcategory

Primitive

SchemeNotationC(2e)C(2e, 2s)

FFC DHdhHybrid1

C(2e)C(2e, 2s)

ECC CDH(Cofactor) Full Unified C(2e, 2s, ECC CDH)
Model

C(2e)

C(2e, 2s)

FFC MQV

MQV2C(2e, 2s, FFC
MQV)

C(2e)

C(2e, 2s)

ECC MQV

Full MQV

C(2e, 2s, ECC
MQV)

C(2e)

C(2e, 0s)

FFC DHdhEphemC(2e, 0s, FFC DH)

C(2e)C(2e, 0s)

ECC CDH(Cofactor) Ephemeral
Unified ModelC(2e, 0s, ECC CDH)

C(1e)C(1e, 2s)

FFC DHdhHybridOneFlow

C(1e, 2s, FFC DH)

C(1e)C(1e, 2s)

ECC CDH(Cofactor) One-Pass
Unified ModelC(1e, 2s, ECC CDH)

C(1e)C(1e, 2s)

FFC MQV

MQV1C(1e, 2s, FFC
MQV)

C(1e)

C(1e, 2s)

ECC MQV

One-Pass MQV

C(1e, 2s, ECC
MQV)

C(1e)

C(1e, 1s)

FFC DH

dhOneFlowC(1e, 1s, FFC DH)

65

C(2e, 2s, FFC DH)NIST SP 800-56A Rev. 3

Category Subcategory

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

Primitive

SchemeNotationC(1e)C(1e, 1s)

ECC CDH(Cofactor) One-Pass
Diffie-Hellman

C(1e, 1s, ECC CDH)

C(0e)C(0e, 2s)

FFC DHdhStatic

C(0e, 2s, FFC DH)

C(0e)C(0e, 2s)

ECC CDH(Cofactor) Static Unified C(0e, 2s, ECC CDH)
Model

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Each party in a key-agreement process shall use the same set of valid domain parameters.
These parameters shall be established, and assurance of their validity shall be obtained prior
to the generation of key pairs and the initiation of the key-agreement process. See Section
5.5 for a discussion of domain parameters.
If party U uses a static key pair in a key-agreement transaction, then party U shall have an
identifier, IDU, that has an association with the static key pair that is known (or discoverable)
and trusted by party V (i.e., there shall be a trusted association between IDU and party U’s
static public key). If party U does not contribute a static public key as part of a key-agreementtransaction, then IDU (if required for that transaction) is a non-null identifier selected inaccordance with the relying application/protocol. Similar rules apply to Party V’s identifier,
IDV.
A general flow diagram is provided for each subcategory of schemes. The dotted-line arrows
represent the distribution of static public keys that may be distributed by the parties
themselves or by a third party, such as a Certification Authority (CA). The solid-line arrows
represent the distribution of ephemeral public keys or nonces that occur during the keyagreement or key-confirmation process. Note that the flow diagrams in this Recommendation
omit explicit mention of various validation checks that are required. The flow diagrams anddescriptions in this Recommendation assume a successful completion of the keyestablishment process. The error conditions are handled in the process text.
For each scheme, there are conditions that must be satisfied to enable proper use of that
scheme. These conditions are listed as the assumptions. Failure to meet all such conditions
could yield undesirable results, such as the inability to communicate or the loss of security.
As part of the proper implementation of this Recommendation, system users and/or agentstrusted to act on their behalf (including application developers, system installers, and systemadministrators) are responsible for ensuring that all assumptions are satisfied at the time a
key-establishment transaction takes place.
6.1

Schemes Using Two Ephemeral Key Pairs, C(2e)In this category, each party generates an ephemeral key pair and sends the ephemeral public
key to the other party. This category consists of two subcategories that are determined by thestatic keys used by the parties. In the first subcategory, each party contributes both static andephemeral keys to the key-agreement computations (see Section 6.1.1), while in the second
subcategory, each party contributes only ephemeral keys (see Section 6.1.2).
66

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

6.1.1 C(2e, 2s) Schemes
Figure_3 depicts a typical flow for a C(2e, 2s) scheme. For these schemes, each party (U andV) contributes a static key pair and generates an ephemeral key pair during the keyagreement process. All key pairs shall be generated using the same domain parameters. Party
U and party V obtain each other’s static public keys, which have been generated prior to the
key-establishment process. Both parties generate ephemeral private/public key pairs andexchange the ephemeral public keys. Using the static and ephemeral keys, both parties
generate a shared secret. The secret keying material is derived from the shared secret.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

UV
U’s Static Public Key
V’s Static Public Key

Obtain static publickeys

U’s Ephemeral Public Key
V’s Ephemeral Public Key

Exchangeephemeralpublic keys

Figure 3: C(2e, 2s) schemes: each party contributes a static and an ephemeral key
pair
Assumptions: In order to execute a C(2e, 2s) key-establishment scheme in compliance withthis Recommendation, the following assumptions shall be true.
1. Each party has an authentic copy of the same set of domain parameters, D, that areapproved for use (see Section 5.5.1). For FFC schemes, D = (p, q, g{, SEED,
counter}); for ECC schemes, D = (q, FR, a, b{, SEED}, G, n, h). Furthermore, eachparty has obtained assurance of the validity of these domain parameters as specified
in Section 5.5.2.
2. Each party has been designated as the owner of a static key pair that was generated
as specified in Section 5.6.1 using the set of domain parameters, D. For FFC schemes,
the static key pair is (x, y); for ECC schemes, the static key pair is (ds, Qs). Each party
has obtained assurance of the validity of its own static public key as specified in
Section 5.6.2.1.3 and has obtained assurance of its possession of the correct value forits own private key as specified in Section 5.6.2.1.5.
3. The parties have agreed upon an approved key-derivation method, as well as an
approved algorithm to be used with that method (e.g., a hash function) and otherassociated parameters to be used for key derivation (see Section 5.8).
67

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

4. If key confirmation is used, the parties have also agreed upon an approved MAC andassociated parameters, including the lengths of MacKey and MacTag, as specified in
Section 5.9.3).
5. Prior to or during the key-agreement process, each party receives the other party’s
static public key in a trusted manner (e.g., from a certificate signed by a trusted CA
or directly from the other party, who is trusted by the recipient). Each party has
obtained assurance of the validity of the other party’s static public key as specified in
Section 5.6.2.2.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

6. The recipient of a static public key has obtained assurance that its (claimed) owner is(or was) in possession of the corresponding static private key, as specified in Section
5.6.2.2.3.
7. When an identifier is used to label a party during the key-agreement process, that
identifier has a trusted association to that party’s static public key. (In other words,
whenever both the identifier and static public key of one participant are employed in
the key-agreement process, they are associated in a manner that is trusted by the otherparticipant.) When an identifier is used to label a party during the key-agreement
process, both parties are aware of the identifier employed for that purpose.
6.1.1.1 dhHybrid1, C(2e, 2s, FFC DH) Scheme
This section describes the dhHybrid1 scheme. Assurance of secure key establishment using
this scheme can only be obtained when the assumptions in Section 6.1.1 are true. In
particular, it is assumed that party U has obtained the static public key yV of party V, andparty V has obtained the static public key yU of party U.
With the exception of key derivation, the dhHybrid1 scheme is “symmetric” in the actionsof parties U and V. Only the actions performed by party U are specified here; a specificationof the actions performed by party V may be obtained by systematically replacing the letter“U” by “V” (and vice versa) in the actions listed below. Note, however, that parties U and V
must use identical orderings of the bit strings that are input to the key-derivation method.
Party U shall execute the following actions to a) establish a shared secret value Z with party
V, and b) derive secret keying material from Z.
Actions: Party U generates a shared secret and derives secret keying material as follows:
1. Generate an ephemeral key pair (rU, tU) from the domain parameters D as specified in
Section 5.6.1.1. Send the public key tU to party V. Receive an ephemeral public keytV (purportedly) from party V. If tV is not received, destroy the ephemeral private key
rU, then output an error indicator, and exit this process without performing theremaining actions.
2. Verify that tV is a valid ephemeral public key for the parameters D as specified in
Section 5.6.2.3. If assurance of public key validity cannot be obtained, destroy theephemeral private key rU; then, output an error indicator, and exit this process without
performing the remaining actions.
3. Use the FFC DH primitive in Section 5.7.1.1 to derive a shared secret Zs from the setof domain parameters D, party U’s static private key xU, and party V’s static public
68

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

key yV. If the call to the FFC DH primitive outputs an error indicator, destroy theephemeral private key rU, and destroy the results of all intermediate calculations usedin the attempted computation of Zs; then output an error indicator, and exit thisprocess without performing the remaining actions.
4. Use the FFC DH primitive to derive a shared secret Ze from the set of domain
parameters D, party U’s ephemeral private key rU, and party V’s ephemeral public
key tV. If this call to the FFC DH primitive outputs an error indicator, destroy Zs andthe ephemeral private key rU,, and destroy the results of all intermediate calculations
used in the attempted computation of Ze; then, output an error indicator, and exit thisprocess without performing the remaining actions.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

5. Compute the shared secret Z = Ze || Zs. Destroy Ze and Zs.
6. Use the agreed-upon key-derivation method to derive secret keying material with thespecified length from the shared secret value Z and other input (see Section 5.8). If
the key-derivation method outputs an error indicator, destroy all copies of Z and theephemeral private key rU, then output an error indicator, and exit this process without
performing the remaining actions.
7. Destroy rU and all copies of the shared secret Z.
8. Output the derived keying material.
Output: The derived keying material or an error indicator.
Note: Key confirmation can be incorporated into this scheme. See Section 6.1.1.5 for details.
dhHybrid1 is summarized in Table 9.
Table 9: dhHybrid1 key-agreement scheme summary
Party U

Party V

Domainparameters

D = (p, q, g{, SEED, counter})

D = (p, q, g{, SEED, counter})

Static Data

Static private key xU

Static private key xV

Static public key yU

Static public key yV

Ephemeral private key rU

Ephemeral private key rV

Ephemeral public key tU

Ephemeral public key tV

Ephemeral Data

1. Compute Zs by calling FFC 1. Compute Zs by calling FFC DH
DH using xU and yV
using xV and yU
Computation

2. Compute Ze by calling FFC 2. Compute Ze by calling FFC DH
DH using rU and tVusing rV and tU
3. Compute Z = Ze || Zs69

3. Compute Z = Ze || Zs

NIST SP 800-56A Rev. 3

Derive SecretKeying Material

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

1. Compute
DerivedKeyingMaterial

1. Compute
DerivedKeyingMaterial

2. Destroy Z

2. Destroy Z

6.1.1.2 (Cofactor) Full Unified Model, C(2e, 2s, ECC CDH) Scheme
This section describes the Full Unified Model scheme. Assurance of secure key
establishment using this scheme can only be obtained when the assumptions in Section 6.1.1
are true. In particular, it is assumed that party U has obtained the static public key Qs,V ofparty V, and party V has obtained the static public key Qs,U of party U.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

With the exception of key derivation, the Full Unified Model scheme is “symmetric” in theactions of parties U and V. Only the actions performed by party U are specified here; aspecification of the actions performed by party V may be obtained by systematicallyreplacing the letter “U” by “V” (and vice versa) in the actions listed below. Note, however,that parties U and V must use identical orderings of the bit strings that are input to the keyderivation method.
Party U shall execute the following actions to a) establish a shared secret value Z with party
V, and b) derive secret keying material from Z.
Actions: Party U generates a shared secret and derives secret keying material as follows:
1. Generate an ephemeral key pair (de,U, Qe,U) from the domain parameters D as specified
in Section 5.6.1.2. Send the public key Qe,U to party V. Receive an ephemeral public
key Qe,V (purportedly) from party V. If Qe,V is not received, destroy the ephemeral
private key de,U; then output an error indicator, and exit this process without
performing the remaining actions.
2. Verify that Qe,V is a valid ephemeral public key for the parameters D as specified in
Section 5.6.2.3. If assurance of public key validity cannot be obtained, destroy theephemeral private key de,U, then output an error indicator, and exit this process
without performing the remaining actions.
3. Use the ECC CDH primitive in Section 5.7.1.2 to derive a shared secret Zs from theset of domain parameters D, party U’s static private key ds,U, and party V’s static
public key Qs,V. If the call to the ECC CDH primitive outputs an error indicator,
destroy the ephemeral private key de,U, and destroy the results of all intermediate
calculations used in the attempted computation of Zs; then output an error indicator,and exit this process without performing the remaining actions.
4. Use the ECC CDH primitive to derive a shared secret Ze from the set of domain
parameters D, party U’s ephemeral private key de,U, and party V’s ephemeral public
key Qe,V. If this call to the ECC CDH primitive outputs an error indicator, destroy Zs
and the ephemeral private key de,U, and destroy the results of all intermediate
calculations used in the attempted computation of Ze; then output an error indicator,and exit this process without performing the remaining actions.
5. Compute the shared secret Z = Ze || Zs. Destroy Ze and Zs.
70

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

6. Use the agreed-upon key-derivation method to derive secret keying material with thespecified length from the shared secret value Z and other input (see Section 5.8). If
the key-derivation method outputs an error indicator, destroy all copies of Z and theephemeral private key de,U; then output an error indicator, and exit this process
without performing the remaining actions.
7. Destroy de,U and all copies of the shared secret Z.
8.

Output the derived keying material.

Output: The derived keying material or an error indicator.
Note: Key confirmation can be incorporated into this scheme. See Section 6.1.1.5 for details.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

The Full Unified Model is summarized in Table 10.
Table 10: Full unified model key-agreement scheme summary
Party U

Party V

Domainparameters

D = (q, FR, a, b{, SEED}, G, n, h) D = (q, FR, a, b{, SEED}, G, n, h)

Static data

Static private key ds,U

Static private key ds,VStatic public key Qs,U

Static public key Qs,V

Ephemeral private key de,U

Ephemeral private key de,V

Ephemeral public key Qe,U

Ephemeral public key Qe,V

Ephemeral data

1. Compute Zs by calling ECC 1. Compute Zs by calling ECC
CDH using ds,U and Qs,V
CDH using ds,V and Qs,U
Computation

Derive secretkeying material

2. Compute Ze by calling ECC 2. Compute Ze by calling ECC
CDH using de,U and Qe,V
CDH using de,V and Qe,U
3. Compute Z = Ze || Zs

3. Compute Z = Ze || Zs

1. Compute
DerivedKeyingMaterial

1. Compute
DerivedKeyingMaterial

2. Destroy Z

2. Destroy Z

6.1.1.3 MQV2, C(2e, 2s, FFC MQV) Scheme
This section describes the MQV2 scheme. Assurance of secure key establishment using thisscheme can only be obtained when the assumptions in Section 6.1.1 are true. In particular, it
is assumed that party U has obtained the static public key yV of party V, and party V has
obtained the static public key yU of party U.
With the exception of key derivation, MQV2 is “symmetric” in the actions of parties U and
V. Only the actions performed by party U are specified here; a specification of the actions
71

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

performed by party V may be obtained by systematically replacing the letter “U” by “V”(and vice versa) in the actions listed below. Note, however, that parties U and V must use
identical orderings of the bit strings that are input to the key-derivation method.
Party U shall execute the following actions to a) establish a shared secret value Z with party
V, and b) derive secret keying material from Z.
Actions: Party U generates a shared secret and derives secret keying material as follows:This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

1. Generate an ephemeral key pair (rU, tU) from the domain parameters D as specified in
Section 5.6.1.1. Send the public key tU to party V. Receive an ephemeral public keytV (purportedly) from party V. If tV is not received, destroy the ephemeral private key
rU; then output an error indicator, and exit this process without performing theremaining actions.
2. Verify that tV is a valid ephemeral public key for the parameters D as specified in
Section 5.6.2.3. If assurance of public key validity cannot be obtained, destroy theephemeral private key rU; then output an error indicator, and exit this process without
performing the remaining actions.
3. Use the MQV2 form of the FFC MQV primitive in Section 5.7.2.1 to derive a sharedsecret Z from the set of domain parameters D, party U’s static private key xU, party
V’s static public key yV, party U’s ephemeral private key rU, party U’s ephemeral
public key tU, and party V’s ephemeral public key tV. If the call to the FFC MQVprimitive outputs an error indicator, destroy the ephemeral private key rU, and destroy
the results of all intermediate calculations used in the attempted computation of Z;
then output an error indicator, and exit this process without performing the remaining
actions.
4. Use the agreed-upon key-derivation method to derive secret keying material with thespecified length from the shared secret value Z and other input (see Section 5.8). If
the key-derivation method outputs an error indicator, destroy all copies of Z and theephemeral private key rU; then output an error indicator, and exit this process without
performing the remaining actions.
5. Destroy rU and all copies of the shared secret Z.
6. Output the derived keying material.
Output: The derived keying material or an error indicator.
Note: Key confirmation can be incorporated into this scheme. See Section 6.1.1.5 for details.
MQV2 is summarized in Table 11.
Table 11: MQV2 key-agreement scheme summary
Party U
Domainparameters

Party VD = (p, q, g{, SEED, counter})

72

D = (p, q, g{, SEED, counter})NIST SP 800-56A Rev. 3

Static data
Ephemeral
data
Computation

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Derive secretkeyingmaterial

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

Static private key xU

Static private key xV

Static public key yU

Static public key yV

Ephemeral private key rU

Ephemeral private key rV

Ephemeral public key tU

Ephemeral public key tVCompute Z by calling FFC MQV Compute Z by calling FFC MQVusing xU, yV, rU, tU, and tVusing xV, yU, rV, tV, and tU
1. Compute
DerivedKeyingMaterial

1. Compute
DerivedKeyingMaterial

2. Destroy Z

2. Destroy Z

6.1.1.4 Full MQV, C(2e, 2s, ECC MQV) Scheme
This section describes the Full MQV scheme. Assurance of secure key establishment using
this scheme can only be obtained when the assumptions in Section 6.1.1 are true. In
particular, it is assumed that party U has obtained the static public key Qs,V of party V, andparty V has obtained the static public key Qs,U of party U.
With the exception of key derivation, the Full MQV scheme is “symmetric” in the actions ofparties U and V. Only the actions performed by party U are specified here; a specification of
the actions performed by party V may be obtained by systematically replacing the letter “U”
by “V” (and vice versa) in the actions listed below. Note, however, that parties U and V must
use identical orderings of the bit strings that are input to the key-derivation method.
Party U shall execute the following actions to a) establish a shared secret value Z with party
V, and b) derive secret keying material from Z.
Actions: Party U generates a shared secret and derives secret keying material as follows:
1. Generate an ephemeral key pair (de,U, Qe,U) from the domain parameters D as specified
in Section 5.6.1.2. Send the public key Qe,U to party V. Receive an ephemeral public
key Qe,V (purportedly) from party V. If Qe,V is not received, destroy the ephemeral
private key de,U; then output an error indicator, and exit this process without
performing the remaining actions.
2. Verify that Qe,V is a valid ephemeral public key for the parameters D as specified in
Section 5.6.2.3. If assurance of public key validity cannot be obtained, destroy theephemeral private key de,U; then output an error indicator, and exit this process
without performing the remaining actions.
3. Use the Full MQV form of the ECC MQV primitive in Section 5.7.2.3.1 to derive ashared secret value Z from the set of domain parameters D, party U’s static private
key ds,U, party V’s static public key Qs,V, party U’s ephemeral private key de,U, party
U’s ephemeral public key Qe,U, and party V’s ephemeral public key Qe,V. If the call to
the ECC MQV primitive outputs an error indicator, destroy the ephemeral private
key de,U, and destroy the results of all intermediate calculations used in the attempted
73

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

computation of Z; then output an error indicator, and exit this process without
performing the remaining actions.
4. Use the agreed-upon key-derivation method to derive secret keying material with thespecified length from the shared secret value Z and other input (see Section 5.8). If
the key-derivation method outputs an error indicator, destroy all copies of Z and theephemeral private key de,U; then output an error indicator, and exit this process
without performing the remaining actions.
5. Destroy de,U and all copies of the shared secret Z.
6. Output the derived keying material.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Output: The derived keying material or an error indicator.
Note: Key confirmation can be incorporated into this scheme. See Section 6.1.1.5 for details.
The Full MQV is summarized in Table 12.
Table 12: Full MQV key-agreement scheme summary
Party U

Party V

Domainparameters

D = (q, FR, a, b{, SEED}, G, n, h) D = (q, FR, a, b{, SEED}, G, n, h)

Static data

1. Static private key ds,U

1. Static private key ds,V

2. Static public key Qs,U

2. Static public key Qs,V

1. Ephemeral private key de,U

1. Ephemeral private key de,V

2. Ephemeral public key Qe,U

2. Ephemeral public key Qe,V

Ephemeral data

Computation

Derive secretkeying material

Compute Z by calling ECC MQV Compute Z by calling ECC MQVusing ds,U, Qs,V, de,U, Qe,U, and Qe,V using ds,V, Qs,U, de,V, Qe,V, and Qe,U
1. Compute
DerivedKeyingMaterial

1. Compute
DerivedKeyingMaterial

2. Destroy Z

2. Destroy Z

6.1.1.5 Incorporating Key Confirmation into a C(2e, 2s) Scheme
The subsections that follow illustrate how to incorporate key confirmation (as described in
Section 5.9) into the C(2e, 2s) key-agreement schemes described above.
The flow depictions separate the key-establishment flow from the key-confirmation flow.
The depictions and accompanying discussions presume that the assumptions of the scheme
have been satisfied, that the key-agreement transaction has proceeded successfully throughkey derivation, and that the received MacTags are successfully verified as specified in
Section 5.2.2.
74

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

6.1.1.5.1 C(2e, 2s) Scheme with Unilateral Key Confirmation Provided by Party U to
Party V

Figure_4 depicts a typical flow for a C(2e, 2s) scheme with unilateral key confirmation fromparty U to party V. In this scenario, party U and party V assume the roles of key-confirmation
provider and recipient, respectively. The successful completion of this process provides party
V with a) assurance that party U has derived the same secret Z value, and b) assurance thatparty U has actively participated in the process.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

UV
U’s Static Public Key
V’s Static Public Key

Obtain static
public keys

U’s Ephemeral Public Key
V’s Ephemeral Public Key
MacTagU

Exchangeephemeralpublic keys

U’s keyconfirmation

Figure 4: C(2e, 2s) scheme with unilateral key confirmation from party U to party V
To provide (and receive) key confirmation (as described in Section 5.9.1), party U (and partyV) setEphemDataU = EphemPubKeyU, and EphemDataV = EphemPubKeyV.
Party U provides MacTagU to party V (as specified in Section 5.9.1, with P = U and R = V),
where MacTagU is computed (as specified in Section 5.2.1) using
MacDataU = “KC_1_U” || IDU || IDV || EphemPubKeyU || EphemPubKeyV {|| TextU}.
Party V (the key-confirmation recipient) uses the same format for MacDataU to compute its
own version of MacTagU, and then verifies that the newly computed MacTagU matches thevalue provided by party U.
Party U shall destroy its copy of MacKey immediately after computing MacTagU. Party V
shall immediately destroy its copy of MacKey after determining whether or not the received
and newly computed MacTagU values match. If they do not match, then party V shall also75

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

destroy the KeyData portion of the DerivedKeyingMaterial (see Section 5.9.1) and notify
party U that MacTagU could not be verified. In this case, party U shall also destroy the
KeyData portion of the DerivedKeyingMaterial.
6.1.1.5.2 C(2e, 2s) Scheme with Unilateral Key Confirmation Provided by Party V to
Party U

Figure_5 depicts a typical flow for a C(2e, 2s) scheme with unilateral key confirmation fromparty V to party U. In this scenario, party V and party U assume the roles of key-confirmation
provider and recipient, respectively. The successful completion of the key-confirmation
process provides party U with a) assurance that party V has derived the same secret Z value,and b) assurance that party V has actively participated in the process.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

UV
U’s Static Public Key
V’s Static Public Key

U’s Ephemeral Public Key

V’s Ephemeral Public Key, MacTagVObtain static
public keys
U sends anephemeralpublic key
V sends anephemeral publickey with key
confirmation

Figure 5: C(2e, 2s) scheme with unilateral key confirmation from party V to party U
To provide (and receive) key confirmation (as described in Section 5.9.1), party V (and partyU) setEphemDataV = EphemPubKeyV, and EphemDataU = EphemPubKeyU.
Party V provides MacTagV to party U (as specified in Section 5.9.1, with P = V and R = U),
where MacTagV is computed (as specified in Section 5.2.1) using
MacDataV = “KC_1_V” || IDV || IDU || EphemPubKeyV || EphemPubKeyU {|| TextV}.
Party U (the key-confirmation recipient) uses the same format for MacDataV to compute its
own version of MacTagV and then verifies that the newly computed MacTagV matches thevalue provided by party V.
Note that in Figure_5, party V’s ephemeral public key (EphemPubKeyV) and the MacTag(MacTagV) are depicted as being sent in the same message (to reduce the number of passes
76

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

in the combined key-agreement/key-confirmation process). They may also be sent
separately.
Party V shall destroy its copy of MacKey immediately after computing MacTagV. Party U
shall immediately destroy its copy of MacKey after determining whether or not the received
and newly computed MacTagV values match. If they do not match, then party U shall also
destroy the KeyData portion of the DerivedKeyingMaterial (see Section 5.9.1) and notify
party V that MacTagV could not be verified. In this case, party V shall also destroy the
KeyData portion of the DerivedKeyingMaterial.
6.1.1.5.3 C(2e, 2s) Scheme with Bilateral Key Confirmation
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Figure_6 depicts a typical flow for a C(2e, 2s) scheme with bilateral key confirmation. In
this method, party U and party V assume the roles of both the provider and the recipient inorder to obtain bilateral key confirmation. The successful completion of the key-confirmation
process provides each party with a) assurance that the other party has derived the same secret
Z value, and b) assurance that the other party has actively participated in the process.

U

V
U’s Static Public Key
V’s Static Public Key

Obtain static
public keys

U’s Ephemeral Public Key

U sends an ephemeral
public key

V’s Ephemeral Public Key, MacTagV

V sends an ephemeral
public key with key
confirmation

MacTagU

U’s key
confirmation

Figure 6: C(2e, 2s) scheme with bilateral key confirmation
To provide bilateral key confirmation (as described in Section 5.9.2), party U and party V
exchange and verify MacTags that have been computed (as specified in Section 5.2.1) using
EphemDataU = EphemPubKeyU, and EphemDataV = EphemPubKeyV.
Party V provides MacTagV to party U (as specified in Sections 5.9.1 and 5.9.2, with P = V
and R = U); MacTagV is computed by party V (and verified by party U) using
MacDataV = “KC_2_V” || IDV || IDU || EphemPubKeyV || EphemPubKeyU {|| TextV}.
77

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

Party U provides MacTagU to party V (as specified in Sections 5.9.1 and 5.9.2, with P = U
and R = V); MacTagU is computed by party U (and verified by party V) using
MacDataU = “KC_2_U” || IDU || IDV || EphemPubKeyU || EphemPubKeyV {|| TextU}.
Note that in Figure_6, party V’s ephemeral public key (EphemPubKeyV) and the MacTag(MacTagV) are depicted as being sent in the same message (to reduce the number of passes
in the combined key-agreement/key-confirmation process). They may also be sent
separately, and if sent separately, then the order in which the MacTags are sent could bereversed.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Each party shall destroy its copy of MacKey immediately after 1) using it to generate a MAC
tag to be sent to the other party and 2) determining whether or not the MAC tag received
from the other party matches the MAC tag that it computed. However, if either party is notable to verify the received MAC tag, that party shall also destroy the KeyData portion of the
DerivedKeyingMaterial (see Section 5.9.1) and notify the other party of the failure. In thiscase, the other party shall destroy both the MacKey (if it has not already done so) as well as
the KeyData portion of the DerivedKeyingMaterial.
6.1.2 C(2e, 0s) Schemes
For this category, only Diffie-Hellman schemes are specified. Each party generates
ephemeral key pairs with the same domain parameters. The two parties exchange ephemeral
public keys and then compute the shared secret. The secret keying material is derived using
the shared secret (see Figure 7).

UV
U’s Ephemeral Public Key
V’s Ephemeral Public Key

Exchangeephemeralpublic keys

Figure 7: C(2e, 0s) schemes: each party contributes only an ephemeral key pair
Assumptions: In order to execute a C(2e, 0s) key-establishment scheme in compliance withthis Recommendation, the following assumptions shall be true.
1. Each party has an authentic copy of the same set of domain parameters, D. These
parameters are either approved for use in the intended application (see Section
5.5.1). For FFC schemes, D = (p, q, g{, SEED, counter}); for ECC schemes, D = (q,FR, a, b{, SEED}, G, n, h). Furthermore, each party has obtained assurance of thevalidity of these domain parameters as specified in Section 5.5.2.

78

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

2. The parties have agreed upon an approved key-derivation method, as well as an
approved algorithm to be used with that method (e.g., a hash function) and otherassociated parameters to be used (see Section 5.8).
3. When an identifier is used to label a party during the key-agreement process, it has
been selected/assigned in accordance with the requirements of the protocol relying
upon the use of the key-agreement scheme, and its value is known to both parties.
6.1.2.1 dhEphem, C(2e, 0s, FFC DH) Scheme
This section describes the dhEphem scheme. Assurance of secure key establishment using
this scheme can only be obtained when the assumptions in Section 6.1.2 are true.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

With the exception of key derivation, the dhEphem scheme is “symmetric” in the actions ofparties U and V. Only the actions performed by party U are specified here; a specification of
the actions performed by party V may be obtained by systematically replacing the letter “U”
by “V” (and vice versa) in the actions listed below. Note, however, that parties U and V must
use identical orderings of the bit strings that are input to the key-derivation method.
Party U shall execute the following actions to a) establish a shared secret value Z with party
V, and b) derive secret keying material from Z.
Actions: Party U generates a shared secret and derives secret keying material as follows:
1. Generate an ephemeral key pair (rU, tU) from the domain parameters D as specified in
Section 5.6.1.1. Send the public key tU to party V. Receive an ephemeral public keytV (purportedly) from party V. If tV is not received, destroy the ephemeral private key
rU; then output an error indicator, and exit this process without performing theremaining actions.
2. Verify that tV is a valid ephemeral public key for the parameters D as specified in
Section 5.6.2.3. If assurance of public key validity cannot be obtained, destroy theephemeral key rU; then output an error indicator, and exit this process without
performing the remaining actions.
3. Use the FFC DH primitive in Section 5.7.1.1 to derive a shared secret Z from the setof domain parameters D, party U’s ephemeral private key rU, and party V’s ephemeral
public key tV. Then destroy the ephemeral private key rU. If the call to the FFC DH
primitive outputs an error indicator, destroy the results of all intermediate calculations
used in the attempted computation of Z; then output an error indicator, and exit thisprocess without performing the remaining actions.
4. Use the agreed-upon key-derivation method to derive secret keying material with thespecified length from the shared secret value Z and other input (see Section 5.8). If
the key-derivation method outputs an error indicator, destroy all copies of Z; thenoutput an error indicator, and exit this process without performing the remaining
action.
5. Destroy all copies of the shared secret Z and output the derived keying material.
Output: The derived keying material or an error indicator.
79

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

dhEphem is summarized in Table 13.
Table 13: dhEphem key-agreement scheme summary
Party U

Party VThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Domainparameters(p, q, g{, SEED, counter})(p, q, g{, SEED, counter})

Static data

N/A

N/A

Ephemeral private key rU

Ephemeral private key rV

Ephemeral public key tU

Ephemeral public key tV

Ephemeral data

Computation

Derive secretkeying material

Compute Z by calling FFC DH Compute Z by calling FFC DH
using rU and tVusing rV and tU
1. Compute
DerivedKeyingMaterial

1. Compute
DerivedKeyingMaterial

2. Destroy Z

2. Destroy Z

6.1.2.2 (Cofactor) Ephemeral Unified Model, C(2e, 0s, ECC CDH) Scheme
This section describes the Ephemeral Unified Model scheme. Assurance of secure key
establishment using this scheme can only be obtained when the assumptions in Section 6.1.2
are true.
With the exception of key derivation, the Ephemeral Unified Model scheme is “symmetric”
in the actions of parties U and V. Only the actions performed by party U are specified here;a specification of the actions performed by party V may be obtained by systematicallyreplacing the letter “U” by “V” (and vice versa) in the actions listed below. Note, however,that parties U and V must use identical orderings of the bit strings that are input to the keyderivation method.
Party U shall execute the following actions to a) establish a shared secret value Z with party
V, and b) derive secret keying material from Z.
Actions: Party U generates a shared secret and derives secret keying material as follows:
1. Generate an ephemeral key pair (de,U, Qe,U) from the domain parameters D as specified
in Section 5.6.1.2. Send the public key Qe,U to party V. Receive an ephemeral public
key Qe,V (purportedly) from party V. If Qe,V is not received, destroy the ephemeral
private key de,U; then output an error indicator, and exit this process without
performing the remaining actions.
2. Verify that Qe,V is a valid ephemeral public key for the parameters D as specified in
Section 5.6.2.3. If assurance of public key validity cannot be obtained, destroy theephemeral private key de,U; then output an error indicator, and exit this process
without performing the remaining actions.
80

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

3. Use the ECC CDH primitive in Section 5.7.1.2 to derive a shared secret Z from theset of domain parameters D, party U’s ephemeral private key de,U, and party V’sephemeral public key Qe,V. Then destroy the ephemeral private key de,U. If the call to
the ECC CDH primitive outputs an error indicator, destroy the results of allintermediate calculations used in the attempted computation of Z, then output an error
indicator, and exit this process without performing the remaining actions.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

4. Use the agreed-upon key-derivation method to derive secret keying material with thespecified length from the shared secret value Z and other input (see Section 5.8). If
the key-derivation method outputs an error indicator, destroy all copies of Z; thenoutput an error indicator, and exit this process without performing the remaining
action.
5. Destroy all copies of the shared secret Z and output the derived keying material.
Output: The derived keying material or an error indicator.
The Ephemeral Unified Model is summarized in Table 14.
Table 14: Ephemeral unified model key-agreement scheme summary
Party U

Party V

Domainparameters(q, FR, a, b{, SEED}, G, n, h)(q, FR, a, b{, SEED}, G, n, h)

Static data

N/A

N/A

Ephemeral data

Ephemeral private key de,U

Ephemeral private key de,V

Ephemeral public key Qe,U

Ephemeral public key Qe,V

Computation

Derive secretkeying material

Compute Z by calling ECC CDH Compute Z by calling ECC CDH
using de,U and Qe,V
using de,V and Qe,U
1. Compute
DerivedKeyingMaterial

1. Compute
DerivedKeyingMaterial

2. Destroy Z

2. Destroy Z

6.1.2.3 Key Confirmation for C(2e, 0s) Schemes
In a C(2e, 0s) key-agreement scheme, none of the parties contributes a static key pair. Only
ephemeral key pairs are used to derive the secret value Z. Without a trusted association with
an identifier of either party, key confirmation cannot achieve the expected purposes.
Therefore, in this Recommendation, key confirmation is not incorporated for the C(2e, 0s)
key-agreement schemes.

81

NIST SP 800-56A Rev. 3

6.2

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

Schemes Using One Ephemeral Key Pair, C(1e) Schemes

This category consists of two subcategories that are determined by the use (or non-use) of astatic key pair by each of the parties. Only party U generates an ephemeral key pair. In thefirst subcategory, both party U and party V use a static key pair, and party U also generates
an ephemeral key pair (see Section 6.2.1). In the second subcategory, party U generates an
ephemeral key pair, but uses no static key pair; party V uses only a static key pair (see Section
6.2.2).

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

6.2.1 C(1e, 2s) Schemes
Figure_8 depicts a typical flow for a C(1e, 2s) scheme. For these schemes, party U uses both
static and ephemeral private/public key pairs. Party V uses only a static private/public key
pair. Party U and party V obtain each other’s static public keys in a trusted manner. Party U
also sends its ephemeral public key to party V. A shared secret is generated by both parties
using the available static and ephemeral keys. The secret keying material is derived using theshared secret.

UV
U’s Static Public Key
V’s Static Public Key

U’s Ephemeral Public Key

Obtain static publickeys

U sends an ephemeral
public key

Figure 8: C(1e, 2s) schemes: party U contributes a static and an ephemeral key pairwhile party V contributes only a static key pair
Assumptions: In order to execute a C(1e, 2s) key-establishment scheme in compliance withthis Recommendation, the following assumptions shall be true.
1. Each party has an authentic copy of the same set of domain parameters, D. These
parameters are approved for use in the intended application (see Section 5.5.1). For
FFC schemes, D = (p, q, g{, SEED, counter}); for ECC schemes, D = (q, FR, a, b{,
SEED}, G, n, h). Furthermore, each party has obtained assurance of the validity ofthese domain parameters as specified in Section 5.5.2.
2. Each party has been designated as the owner of a static key pair that was generated
as specified in Section 5.6.1 using the set of domain parameters, D. For FFC schemes,
the static key pair is (x, y); for ECC schemes, the static key pair is (ds, Qs). Each party
82

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

has obtained assurance of the validity of its own static public key as specified in
Section 5.6.2.1.3. Each party has also obtained assurance of its possession of thecorrect value for its own private key as specified in Section 5.6.2.1.5.
3. The parties have agreed upon an approved key-derivation method, as well as an
approved algorithm to be used with that method (e.g., a hash function) and otherassociated parameters to be used for key derivation (see Section 5.8).
4. If key confirmation is used, the parties have also agreed upon an approved MAC andassociated parameters, including the lengths of MacKey and MacTag (see Section
5.9.3). If party V provides key confirmation to party U, the parties have agreed upon
the form of NonceV, which should be a random nonce (see Section 5.4).
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

5. Prior to or during the key-agreement process, each party receives the other party’s
static public key in a trusted manner (e.g., from a certificate signed by a trusted CA
or directly from the other party, who is trusted by the recipient). Each party has
obtained assurance of the validity of the other party’s static public key as specified in
Section 5.6.2.2.1.
6. The recipient of a static public key has obtained assurance that its (claimed) owner is(or was) in possession of the corresponding static private key, as specified in Section
5.6.2.2.3.
7. When an identifier is used to label a party during the key-agreement process, that
identifier has a trusted association to that party’s static public key. (In other words,
whenever both the identifier and static public key of one participant are employed in
the key-agreement process, they are associated in a manner that is trusted by the otherparticipant.) When an identifier is used to label a party during the key-agreement
process, both parties are aware of the particular identifier employed for that purpose.
6.2.1.1 dhHybridOneFlow, C(1e, 2s, FFC DH) Scheme
This section describes the dhHybridOneFlow scheme. Assurance of secure key establishment
using this scheme can only be obtained when the assumptions in Section 6.2.1 are true. In
particular, it is assumed that party U has obtained the static public key yV of party V, andparty V has obtained the static public key yU of party U.
In this scheme, each party has different actions, which are presented separately below.
However, note that parties U and V must use identical orderings of the bit strings that are
input to the key-derivation method.
Party U shall execute the following actions to a) establish a shared secret value Z with party
V, and b) derive secret keying material from Z.
Actions: Party U generates a shared secret and derives secret keying material as follows:
1. Generate an ephemeral key pair (rU, tU) from the domain parameters D as specified
in Section 5.6.1.1. Send the public key tU to party V.
2. Use the FFC DH primitive in Section 5.7.1.1 to derive a shared secret Zs from the setof domain parameters D, party U’s static private key xU, and party V’s static public
83

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

key yV. If the call to the FFC DH primitive outputs an error indicator, destroy theephemeral private key rU, and destroy the results of all intermediate calculations usedin the attempted computation of Zs; then output an error indicator, and exit thisprocess without performing the remaining actions.
3. Use the FFC DH primitive to derive a shared secret Ze from the set of domain
parameters D, party U’s ephemeral private key rU, and party V’s static public key yV.
If this call to the FFC DH primitive outputs an error indicator, destroy Zs and theephemeral private key rU, and destroy the results of all intermediate calculations usedin the attempted computation of Ze; then output an error indicator, and exit thisprocess without performing the remaining actions.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

4. Compute the shared secret Z = Ze || Zs. Destroy Ze and Zs.
5. Use the agreed-upon key-derivation method to derive secret keying material with thespecified length from the shared secret value Z and other input (see Section 5.8). If
the key-derivation method outputs an error indicator, destroy all copies of Z and theephemeral private key rU; then output an error indicator, and exit this process without
performing the remaining actions.
6. Destroy rU and all copies of the shared secret Z.
7. Output the derived keying material.
Output: The derived keying material or an error indicator.
Party V shall execute the following actions to a) establish a shared secret value Z with party
U, and b) derive secret keying material from Z.
Actions: Party V derives secret keying material as follows:
1. Receive an ephemeral public key tU (purportedly) from party U. If tU is not received,
then output an error indicator, and exit this process without performing the remaining
actions.
2. Verify that tU is a valid ephemeral public key for the parameters D as specified in
Section 5.6.2.3. If assurance of public key validity cannot be obtained, then output anerror indicator, and exit this process without performing the remaining actions.
3. Use the FFC DH primitive in Section 5.7.1.1 to derive a shared secret value Zs fromthe set of domain parameters D, party V’s static private key xV, and party U’s static
public key yU. If the call to the FFC DH primitive outputs an error indicator, destroy
the results of all intermediate calculations used in the attempted computation of Zs;
then output an error indicator, and exit this process without performing the remaining
actions.
4. Use the FFC DH primitive to derive a shared secret Ze from the set of domain
parameters D, party V’s static private key xV, and party U’s ephemeral public key tU.
If this call to the FFC DH primitive outputs an error indicator, destroy Zs, and destroy
the results of all intermediate calculations used in the attempted computation of Ze;
then output an error indicator, and exit this process without performing the remaining
actions.
84

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

5. Compute the shared secret Z = Ze || Zs. Destroy Ze and Zs.
6. Use the agreed-upon key-derivation method to derive secret keying material with thespecified length from the shared secret value Z and other input (see Section 5.8). If
the key-derivation method outputs an error indicator, destroy all copies of Z; output
an error indicator and exit this process without performing the remaining action.
7. Destroy all copies of the shared secret Z and output the derived keying material.
Output: The derived keying material or an error indicator.
Note: Key confirmation can be incorporated into this scheme. See Section 6.2.1.5 fordetails.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

dhHybridOneFlow is summarized in Table 15.
Table 15: dhHybridOneFlow key-agreement scheme summary
Party U
Domainparameters
Static data

Ephemeral data

Party V(p, q, g{, SEED, counter})(p, q, g{, SEED, counter})

Static private key xU

Static private key xV

Static public key yU

Static public key yV

Ephemeral private key rU

N/A

Ephemeral public key tU
1. Compute Zs by calling FFC 1. Compute Zs by calling FFC
DH using xU and yV
DH using xV and yU

Computation

Derive secretkeying material

2. Compute Ze by calling FFC 2. Compute Ze by calling FFC
DH using rU and yV
DH using xV and tU
3. Compute Z = Ze || Zs

3. Compute Z = Ze || Zs

1. Compute
DerivedKeyingMaterial

1. Compute
DerivedKeyingMaterial

2. Destroy Z

2. Destroy Z

6.2.1.2 (Cofactor) One-Pass Unified Model, C(1e, 2s, ECC CDH) Scheme
This section describes the One-Pass Unified Model scheme. Assurance of secure key
establishment using this scheme can only be obtained when the assumptions in Section 6.2.1
are true. In particular, it is assumed that party U has obtained the static public key Qs,V ofparty V, and party V has obtained the static public key Qs,U of party U.

85

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

In this scheme, each party has different actions, which are presented separately below.
However, note that parties U and V must use identical orderings of the bit strings that are
input to the key-derivation method.
Party U shall execute the following actions to a) establish a shared secret value Z with party
V, and b) derive secret keying material from Z.
Actions: Party U generates a shared secret and derives secret keying material as follows:
1. Generate an ephemeral key pair (de,U, Qe,U) from the domain parameters D as specified
in Section 5.6.1.2. Send the public key Qe,U to V.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

2. Use the ECC CDH primitive in Section 5.7.1.2 to derive a shared secret Zs from theset of domain parameters D, party U’s static private key ds,U, and party V’s static
public key Qs,V. If the call to the ECC CDH primitive outputs an error indicator,
destroy the ephemeral private key de,U, and destroy the results of all intermediate
calculations used in the attempted computation of Zs; then output an error indicator,and exit this process without performing the remaining actions.
3. Use the ECC CDH primitive to derive a shared secret Ze, from the set of domain
parameters D, party U’s ephemeral private key de,U, and party V’s static public key
Qs,V. If this call to the ECC CDH primitive outputs an error indicator, destroy Zs andthe ephemeral private key de,U, and destroy the results of all intermediate calculations
used in the attempted computation of Ze; then output an error indicator, and exit thisprocess without performing the remaining actions.
4. Compute the shared secret Z = Ze || Zs. Destroy Ze and Zs.
5. Use the agreed-upon key-derivation method to derive secret keying material with thespecified length from the shared secret value Z and other input (see Section 5.8). If
the key-derivation method outputs an error indicator, destroy all copies of Z and theephemeral private key de,U; then output an error indicator, and exit this process
without performing the remaining actions.
6. Destroy de,U and all copies of the shared secret Z.
7. Output the derived keying material.
Output: The derived keying material or an error indicator.
Party V shall execute the following actions to a) establish a shared secret value Z with party
U, and b) derive secret keying material from Z.
Actions: Party V derives secret keying material as follows:
1. Receive an ephemeral public key Qe,U (purportedly) from party U. If Qe,U is notreceived, then output an error indicator, and exit this process without performing theremaining actions.
2. Verify that Qe,U is a valid ephemeral public key for the parameters D as specified in
Section 5.6.2.3. If assurance of public key validity cannot be obtained, then output anerror indicator, and exit this process without performing the remaining actions.
86

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

3. Use the ECC CDH primitive in Section 5.7.1.2 to derive a shared secret Zs from theset of domain parameters D, party V’s static private key ds,V, and party U’s static
public key Qs,U. If the call to the ECC CDH primitive outputs an error indicator,
destroy the results of all intermediate calculations used in the attempted computationof Zs; then output an error indicator, and exit this process without performing theremaining actions.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

4. Use the ECC CDH primitive to derive a shared secret Ze from the set of domain
parameters D, party V’s static private key ds,V, and party U’s ephemeral public key
Qe,U. If this call to the ECC CDH primitive outputs an error indicator, destroy Zs, anddestroy the results of all intermediate calculations used in the attempted computationof Ze; then output an error indicator, and exit this process without performing theremaining actions.
5. Compute the shared secret Z = Ze || Zs. Destroy Ze and Zs.
6. Use the agreed-upon key-derivation method to derive secret keying material with thespecified length from the shared secret value Z and other input (see Section 5.8). If
the key-derivation method outputs an error indicator, destroy all copies of Z; thenoutput an error indicator, and exit this process without performing the remaining
action.
7. Destroy all copies of the shared secret Z and output the derived keying material.
Output: The derived keying material or an error indicator.
Note: Key confirmation can be incorporated into this scheme. See Section 6.2.1.5 fordetails.
The One-Pass Unified Model is summarized in Table 16.
Table 16: One-pass unified model key-agreement scheme summary
Party U
Domainparameters
Static data
Ephemeral data

Party V(q, FR, a, b{, SEED}, G, n, h)(q, FR, a, b{, SEED}, G, n, h)

Static private key ds,U

Static private key ds,VStatic public key Qs,U

Static public key Qs,V

Ephemeral private key de,U

N/A

Ephemeral public key Qe,U

Computation

1. Compute Zs by calling ECC 1. Compute Zs by calling ECC DH
CDH using ds,U and Qs,V
using ds,V and Qs,U
2. Compute Ze by calling ECC 2. Compute Ze by calling ECC DH
CDH using de,U and Qs,V
using ds,V and Qe,U

87

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

Party U

Derive secretkeying material

Party V3. Compute Z = Ze || Zs

3. Compute Z = Ze || Zs

1. Compute
DerivedKeyingMaterial

1. Compute
DerivedKeyingMaterial

2. Destroy Z

2. Destroy Z

6.2.1.3 MQV1, C(1e, 2s, FFC MQV) Scheme
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

This section describes the MQV1 scheme. Assurance of secure key establishment using thisscheme can only be obtained when the assumptions in Section 6.2.1 are true. In particular, it
is assumed that party U has obtained the static public key yV of party V, and party V has
obtained the static public key yU of party U.
In this scheme, each party has different actions, which are presented separately below.
However, note that parties U and V must use identical orderings of the bit strings that are
input to the key-derivation method.
Party U shall execute the following actions in order to a) establish a shared secret value Z
with party V, and b) derive secret keying material from Z.
Actions: Party U generates a shared secret and derives secret keying material as follows:
1. Generate an ephemeral key pair (rU, tU) from the domain parameters D as specified in
Section 5.6.1.1. Send the public key tU to V.
2. Use the MQV1 form of the FFC MQV primitive in Section 5.7.2.1.2 to derive ashared secret Z from the set of domain parameters D, party U’s static private key xU,
party V’s static public key yV, party U’s ephemeral private key rU, party U’s
ephemeral public key tU, and (for a second time) party V’s static public key yV. If thecall to the FFC MQV primitive outputs an error indicator, destroy the ephemeral
private key rU, and destroy the results of all intermediate calculations used in theattempted computation of Z; then output an error indicator, and exit this process
without performing the remaining actions.
3. Use the agreed-upon key-derivation method to derive secret keying material with thespecified length from the shared secret value Z and other input (see Section 5.8). If
the key-derivation method outputs an error indicator, destroy all copies of Z and theephemeral private key rU; then output an error indicator, and exit this process without
performing the remaining actions.
4. Destroy rU and all copies of the shared secret Z.
5. Output the derived keying material.
Output: The derived keying material or an error indicator.
Party V shall execute the following actions to a) establish a shared secret value Z with party
U, and b) derive secret keying material from Z.
88

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

Actions: Party V derives secret keying material as follows:
1. Receive an ephemeral public key tU (purportedly) from party U. If tU is not received,
then output an error indicator, and exit this process without performing the remaining
actions.
2. Verify that tU is a valid ephemeral public key for the parameters D as specified in
Section 5.6.2.3. If assurance of public key validity cannot be obtained, then output anerror indicator, and exit without performing the remaining actions.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

3. Use the MQV1 form of the FFC MQV primitive in Section 5.7.2.1.2 to derive ashared secret Z from the set of domain parameters D, party V’s static private key xV,party U’s static public key yU, party V’s static private key xV (for a second time), party
V’s static public key yV, and party U’s ephemeral public key tU. If the call to the FFC
MQV primitive outputs an error indicator, destroy the results of all intermediate
calculations used in the attempted computation of Z; then output an error indicator,and exit this process without performing the remaining actions.
4. Use the agreed-upon key-derivation method to derive secret keying material with thespecified length from the shared secret value Z and other input (see Section 5.8). If
the key-derivation method outputs an error indicator, destroy all copies of Z; thenoutput an error indicator, and exit this process without performing the remaining
action.
5. Destroy all copies of the shared secret Z and output DerivedKeyingMaterial.
Output: The bit string DerivedKeyingMaterial of length L bits or an error indicator.
Note: Key confirmation can be incorporated into this scheme. See Section 6.2.1.5 fordetails.
MQV1 is summarized in Table 17.
Table 17: MQV1 key-agreement scheme summary.
Party U
Domainparameters
Static data

Ephemeral data

Party V(p, q, g{, SEED, counter})(p, q, g{, SEED, counter})

Static private key xU

Static private key xV

Static public key yU

Static public key yV

Ephemeral private key rU

N/A

Ephemeral public key tUCComputation

Compute Z by calling FFC MQV Compute Z by calling FFC MQVusing xU, yV, rU, tU, and yV (again)using xV, yU, xV (again), yV, and tU

89

NIST SP 800-56A Rev. 3

Derive secretkeying material

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

1. Compute
DerivedKeyingMaterial

1. Compute
DerivedKeyingMaterial

2. Destroy Z

2. Destroy Z

6.2.1.4 One-Pass MQV, C(1e, 2s, ECC MQV) Scheme
This section describes the One-Pass MQV scheme. Assurance of secure key establishment
using this scheme can only be obtained when the assumptions in Section 6.2.1 are true. In
particular, it is assumed that party U has obtained the static public key Qs,V of party V, andparty V has obtained the static public key Qs,U of party U.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

In this scheme, each party has different actions, which are presented separately below.
However, note that party U and party V must use identical orderings of the bit strings thatare input to the key-derivation method.
Party U shall execute the following actions to a) establish a shared secret value Z with party
V, and b) derive secret keying material from Z.
Actions: Party U generates a shared secret and derives secret keying material as follows:
1. Generate an ephemeral key pair (de,U, Qe,U) from the domain parameters D as specified
in Section 5.6.1.2. Send the public key Qe,U to party V.
2. Use the One-Pass MQV form of the ECC MQV primitive in Section 5.7.2.3.2 toderive a shared secret value Z from the set of domain parameters D, party U’s staticprivate key ds,U, party V’s static public key Qs,V, party U’s ephemeral private key de,U,
party U’s ephemeral public key Qe,U, and (for a second time) party V’s static public
key Qs,V. If the call to the ECC MQV primitive outputs an error indicator, destroy theephemeral private key de,U, and destroy the results of all intermediate calculations
used in the attempted computation of Z; then output an error indicator, and exit thisprocess without performing the remaining actions.
3. Use the agreed-upon key-derivation method to derive secret keying material with thespecified length from the shared secret value Z and other input (see Section 5.8). If
the key-derivation method outputs an error indicator, destroy all copies of Z and theephemeral private key de,U; then output an error indicator, and exit this process
without performing the remaining actions.
4. Destroy de,U and all copies of the shared secret Z.
5.

Output the derived keying material.

Output: The derived keying material or an error indicator.
Party V shall execute the following actions to a) establish a shared secret value Z with party
U, and b) derive shared secret keying material from Z.
Actions: Party V derives secret keying material as follows:90

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

1. Receive an ephemeral public key Qe,U (purportedly) from party U. If Qe,U is notreceived, then output an error indicator, and exit this process without performing theremaining actions.
2. Verify that Qe,U is a valid ephemeral public key for the parameters D as specified in
Section 5.6.2.3.2 or 5.6.2.3.3. If assurance of public key validity cannot be obtained,
then output an error indicator, and exit without performing the remaining actions.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

3. Use the One-Pass MQV form of the ECC MQV primitive in Section 5.7.2.3.2 toderive a shared secret value Z from the set of domain parameters D, party V’s staticprivate key ds,V, party U’s static public key Qs,U, party V’s static private key ds,V (for asecond time), party V’s static public key Qs,V, and party U’s ephemeral public key
Qe,U. If the call to the ECC MQV primitive outputs an error indicator, destroy the
results of all intermediate calculations used in the attempted computation of Z; thenoutput an error indicator, and exit this process without performing the remaining
actions.
4. Use the agreed-upon key-derivation method to derive secret keying material with thespecified length from the shared secret value Z and other input (see Section 5.8). If
the key-derivation method outputs an error indicator, destroy all copies of Z; thenoutput an error indicator, and exit this process without performing the remaining
action.
5. Destroy all copies of the shared secret Z and output the derived keying material.
Output: The derived keying material or an error indicator.
Note: Key confirmation can be incorporated into this scheme. See Section 6.2.1.5 fordetails.
The One-Pass MQV scheme is summarized in Table 18.
Table 18: One-pass MQV model key-agreement scheme summary
Party U
Domainparameters
Static data
Ephemeral data

Party V(q, FR, a, b{, SEED}, G, n, h)(q, FR, a, b{, SEED}, G, n, h)

Static private key ds,U

Static private key ds,VStatic public key Qs,U

Static public key Qs,V

Ephemeral private key de,U

N/A

Ephemeral public key Qe,U
Computation

Compute Z by calling ECC MQV Compute Z by calling ECC MQVusing ds,U, Qs,V, de,U, Qe,U, and Qs,V using ds,V, Qs,U, ds,V (again), Qs,V, and(again)Qe,U91

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

Party U
Derive secretKeying material

Party V

1. Compute
DerivedKeyingMaterial

1. Compute
DerivedKeyingMaterial

2. Destroy Z

2. Destroy Z

6.2.1.5 Incorporating Key Confirmation into a C(1e, 2s) Scheme

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

The subsections that follow illustrate how to incorporate key confirmation (as described in
Section 5.9) into the C(1e, 2s) key-agreement schemes described above. Note that party V
cannot act as a key-confirmation recipient unless a nonce (NonceV) is provided by party V toparty U and is used (in addition to the shared secret Z) as input to the key-derivation method
employed by the scheme. This would be accomplished by including (a copy of) NonceV in
the OtherInput provided to the KDM, as part of the FixedInfo (see Section 5.8), in addition
to using (a copy of) NonceV as the EphemDataV employed in the MacTag computations for
key confirmation.
The flow depictions separate the key-establishment flow from the key-confirmation flow.
The depictions and accompanying discussions presume that the assumptions of the scheme
have been satisfied, that the key-agreement transaction has proceeded successfully throughkey derivation, and that the received MacTags are successfully verified as specified in
Section 5.2.2.
6.2.1.5.1 C(1e, 2s) Scheme with Unilateral Key Confirmation Provided by Party U to
Party V

Figure_9 depicts a typical flow for a C(1e, 2s) scheme with unilateral key confirmation fromparty U to party V. In this situation, party U and party V assume the roles of key-confirmation
provider and recipient, respectively. Since party V does not contribute an ephemeral publickey during the key-agreement process, a nonce (NonceV) shall be provided by party V toparty U and used (in addition to the shared secret Z) as input to the key-derivation method
employed by the scheme. NonceV is also used as EphemDataV during MacTag computations.
The successful completion of the key-confirmation process provides party V with assurance
that party U has derived the same secret Z value. If NonceV is a random nonce, then party V
also obtains assurance that party U has actively participated in the process; see Section 5.4
for a discussion of the length and security strength required for the nonce.

92

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

UV
U’s Static Public Key
V’s Static Public Key

U’s Ephemeral Public Key

Obtain static public
keysThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

U sends an ephemeral
public key

NonceVV sends a nonce
MacTagU

U’s key
confirmation

Figure 9: C(1e, 2s) scheme with unilateral key confirmation from party U to party V
To provide (and receive) key confirmation (as described in Section 5.9.1), party U (and partyV) setEphemDataU = EphemPubKeyU, and EphemDataV = NonceV.
Party U provides MacTagU to party V (as specified in Section 5.9.1, with P = U and R = V),
where MacTagU is computed (as specified in Section 5.2.1) using
MacDataU = “KC_1_U” || IDU || IDV || EphemPubKeyU || NonceV {|| TextU}.
Party V (the key-confirmation recipient) uses the same format for MacDataU to compute its
own version of MacTagU and then verifies that the newly computed MacTag matches thevalue provided by party U.
Party U shall destroy its copy of MacKey immediately after computing MacTagU. Party V
shall immediately destroy its copy of MacKey after determining whether or not the received
and newly computed MacTagU values match. If they do not match, then party V shall also
destroy the KeyData portion of the DerivedKeyingMaterial (see Section 5.9.1) and notify
party U that MacTagU could not be verified. In this case, party U shall also destroy the
KeyData portion of the DerivedKeyingMaterial.

93

NIST SP 800-56A Rev. 3

6.2.1.5.2

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

C(1e, 2s) Scheme with Unilateral Key Confirmation Provided by Party V to
Party U

Figure_10 depicts a typical flow for a C(1e, 2s) scheme with unilateral key confirmationfrom party V to party U. In this scenario, party V and party U assume the roles of keyconfirmation provider and recipient, respectively. The successful completion of the keyconfirmation process provides party U with a) assurance that party V has derived the same
secret Z value, and b) assurance that party V has actively participated in the process.

U

V

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

U’s Static Public Key
V’s Static Public Key

U’s Ephemeral Public Key
MacTagV

Obtain static publickeys

U sends an ephemeral
public key
V’s keyconfirmation

Figure 10: C(1e, 2s) scheme with unilateral key confirmation from party V to party U
To provide (and receive) key confirmation (as described in Section 5.9.1), both parties set
EphemDataV = Null, and EphemDataU = EphemPubKeyU.
Party V provides MacTagV to party U (as specified in Section 5.9.1, with P = V and R = U),
where MacTagV is computed (as specified in Section 5.2.1) using
MacDataV = “KC_1_V” || IDV || IDU || Null || EphemPubKeyU {|| TextV}.
Party U (the key-confirmation recipient) uses the same format for MacDataV to compute its
own version of MacTagV, and then verifies that the newly computed MacTag matches thevalue provided by party V.
Party V shall destroy its copy of MacKey immediately after computing MacTagV. Party U
shall immediately destroy its copy of MacKey after determining whether or not the received
and newly computed MacTagV values match. If they do not match, then party U shall also
destroy the KeyData portion of the DerivedKeyingMaterial (see Section 5.9.1) and notify
party V that MacTagV could not be verified. In this case, party V shall also destroy the
KeyData portion of the DerivedKeyingMaterial.

94

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

6.2.1.5.3 C(1e, 2s) Scheme with Bilateral Key Confirmation

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Figure_11 depicts a typical flow for a C(1e, 2s) scheme with bilateral key confirmation. In
this method, party U and party V assume the roles of both the provider and the recipient toobtain bilateral key confirmation. Since party V does not contribute an ephemeral public key
during the key-agreement process, a nonce (NonceV) shall be provided by party V to party U
and used (in addition to the shared secret Z) as input to the key-derivation method employedby the scheme. NonceV is also used as the EphemDataV during MacTag computations. The
successful completion of the key-confirmation process provides each party with assurance
that the other party has derived the same secret Z value. Party U obtains assurance that party
V has actively participated in the process; if NonceV is a random nonce, then party V also
obtains assurance that party U has actively participated in the process; see Section 5.4 for a
discussion of the length and security strength required for the nonce.

UV
U’s Static Public Key
V’s Static Public Key

Obtain static publickeys

U’s Ephemeral Public Key

U sends an ephemeral
public key

NonceV, MacTagV

V’s key confirmation
with a nonce

MacTagU
U’s key confirmation

Figure 11: C(1e, 2s) scheme with bilateral key confirmation
To provide bilateral key confirmation (as described in Section 5.9.2), party U and party V
exchange and verify MacTags that have been computed (as specified in Sections 5.2.1) using
EphemDataU = EphemPubKeyU and EphemDataV = NonceV.
Party V provides MacTagV to party U (as specified in Sections 5.9.1 and 5.9.2, with P = V
and R = U); MacTagV is computed by party V (and verified by U) using
MacDataV = “KC_2_V” || IDV || IDU || NonceV || EphemPubKeyU {|| TextV}.
Party U provides MacTagU to party V (as specified in Sections 5.9.1 and 5.9.2, with P = U
and R = V); MacTagU is computed by party U (and verified by party V) using
MacDataU = “KC_2_U” || IDU || IDV || EphemPubKeyU || NonceV {|| TextU}.

95

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

Note that in Figure_11 party V’s nonce (NonceV) and the MacTag (MacTagV) are depicted as
being sent in the same message (to reduce the number of passes in the combined keyagreement/key-confirmation process). They may also be sent separately (as long as NonceV
is sent before the MacTags are exchanged). The MacTagV and MacTagU can be sent in any
order, as long as NonceV is available to generate and verify both MAC tags.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Each party shall destroy its copy of MacKey immediately after 1) using it to generate a MAC
tag to be sent to the other party and 2) determining whether or not the MAC tag received
from the other party matches the MAC tag that it computed. However, if either party is notable to verify the received MAC tag, that party shall also destroy the KeyData portion of the
DerivedKeyingMaterial (see Section 5.9.1) and notify the other party of the failure. In thiscase, the other party shall destroy both the MacKey (if it has not already done so) as well as
the KeyData portion of the DerivedKeyingMaterial.
6.2.2 C(1e, 1s) Schemes
For each of the C(1e, 1s) schemes, party U generates an ephemeral key pair, but uses nostatic key pair; party V has only a static key pair. Party U obtains party V’s static public key
in a trusted manner (for example, from a certificate signed by a trusted CA or directly fromparty V, who is trusted) and sends its ephemeral public key to party V. The parties computea shared secret using their private keys and the other party’s public key. Each party uses theshared secret to derive secret keying material (see Figure 12).

UV
V’s Static Public Key

U’s Ephemeral Public Key

U obtains V’s static
public key

U sends an ephemeral
public key

Figure 12: C(1e, 1s) schemes: party U contributes an ephemeral key pair, and party V
contributes a static key pair
Assumptions: In order to execute a C(1e, 1s) key-establishment scheme in compliance withthis Recommendation, the following assumptions shall be true.
1. Each party has an authentic copy of the same set of domain parameters, D. These
parameters are either approved for use in the intended application (see Section
5.5.1). For FFC schemes, D = (p, q, g{, SEED, counter}); for ECC schemes, D = (q,FR, a, b{, SEED}, G, n, h). Furthermore, each party has obtained assurance of thevalidity of these domain parameters as specified in Section 5.5.2.
96

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

2. Party V has been designated as the owner of a static key pair that was generated as
specified in Section 5.6.1 using the set of domain parameters, D. For FFC schemes,
the static key pair is (x, y); for ECC schemes, the static key pair is (ds, Qs). Party V
has obtained assurance of the validity of its own static public key as specified in
Section 5.6.2.1. Party V has obtained assurance of its possession of the correct valueof its own private key as specified in Section 5.6.2.1.5.
3. The parties have agreed upon an approved key-derivation method, as well as an
approved algorithm to be used with that method (e.g., a hash function) and otherassociated parameters to be used (see Section 5.8).
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

4. If key confirmation is used, the parties have also agreed upon an approved MAC andassociated parameters, including the lengths of MacKey and MacTag (see Section
5.9.3).
5. Prior to or during the key-agreement process, party U receives party V’s static public
key in a trusted manner (e.g., from a certificate signed by a trusted CA or directlyfrom party V, who is trusted by the recipient). Party U has obtained assurance of thevalidity of party V’s static public key as specified in Section 5.6.2.2.1.
6. When an identifier is used to label either party during the key-agreement process,both parties are aware of the identifier employed for that purpose. In particular, when
an identifier is used to label party V during the key-agreement process, that identifier
has a trusted association to party V’s static public key. (In other words, wheneverboth the identifier and static public key of one participant are employed in the keyagreement process, they are associated in a manner that is trusted by the otherparticipant.) When an identifier is used to label party U during the key-agreement
process, it has been selected/assigned in accordance with the requirements of the
protocol relying upon the use of the key-agreement scheme.
The following is an assumption for using the derived keying material for purposes beyond
the C(1e,1s) scheme itself.
Party U has obtained assurance that party V is (or was) in possession of theappropriate static private key, as specified in Section 5.6.2.2.3.
6.2.2.1 dhOneFlow, C(1e, 1s, FFC DH) Scheme
This section describes the dhOneFlow scheme. Assurance of secure key establishment using
this scheme can only be obtained when the assumptions in Section 6.2.2 are true. In
particular, it is assumed that party U has obtained the static public key yV of party V.
In this scheme, each party has different actions, which are presented separately below.
However, note that parties U and V must use identical orderings of the bit strings that are
input to the key-derivation method.
Party U shall execute the following actions to a) establish a shared secret value Z with party
V, and b) derive secret keying material from Z.
Actions: Party U generates a shared secret and derives secret keying material as follows:97

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

1. Generate an ephemeral key pair (rU, tU) from the domain parameters D as specified in
Section 5.6.1.1. Send the public key tU to party V.
2. Use the FFC DH primitive in Section 5.7.1.1 to derive a shared secret Z from the setof domain parameters D, party U’s ephemeral private key rU, and party V’s static
public key yV. If the call to the FFC DH primitive outputs an error indicator, destroy
the ephemeral private key rU, and destroy the results of all intermediate calculations
used in the attempted computation of Z; then output an error indicator, and exit thisprocess without performing the remaining actions.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

3. Use the agreed-upon key-derivation method to derive secret keying material with thespecified length from the shared secret value Z and other input (see Section 5.8). If
the key-derivation method outputs an error indicator, destroy all copies of Z and theephemeral private key rU; then output an error indicator, and exit this process without
performing the remaining actions.
4. Destroy rU and all copies of the shared secret Z.
5. Output the derived keying material.
Output: The derived keying material or an error indicator.
Party V shall execute the following actions to a) establish a shared secret value Z with party
U, and b) derive secret keying material from Z.
Actions: Party V derives secret keying material as follows:
1. Receive an ephemeral public key tU (purportedly) from party U. If tU is not received,
then output an error indicator, and exit this process without performing the remaining
actions.
2. Verify that tU is a valid ephemeral public key for the parameters D as specified in
Section 5.6.2.3. If assurance of public key validity cannot be obtained, then output anerror indicator, and exit this process without performing the remaining actions.
3. Use the FFC DH primitive in Section 5.7.1.1 to derive a shared secret Z from the setof domain parameters D, party V’s static private key xV, and party U’s ephemeral
public key tU. If the call to the FFC DH primitive outputs an error indicator, destroy
the results of all intermediate calculations used in the attempted computation of Z;
then output an error indicator, and exit this process without performing the remaining
actions.
4. Use the agreed-upon key-derivation method to derive secret keying material with thespecified length from the shared secret value Z and other input (see Section 5.8). If
the key-derivation method outputs an error indicator, destroy all copies of Z; thenoutput an error indicator, and exit this process without performing the remaining
action.
5. Destroy all copies of the shared secret Z and output the derived keying material.
Output: The derived keying material or an error indicator.

98

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

Note: Key confirmation can be incorporated into this scheme. See Section 6.2.2.3 fordetails.
dhOneFlow is summarized in Table 19.
Table 19: dhOneFlow key-agreement scheme summary
Party U
Domainparameters
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Static data

Ephemeral data

Computation

Derive secretmaterial

Party V(p, q, g{, SEED, counter})(p, q, g{, SEED, counter})

N/A

Static private key xV
Static public key yV

Ephemeral private key rU

N/A

Ephemeral public key tU
Compute Z by calling FFC DH Compute Z by calling FFC DH using
using rU and yV
xV and tU
1. Compute
DerivedKeyingMaterial

1. Compute
DerivedKeyingMaterial

2. Destroy Z

2. Destroy Z

6.2.2.2 (Cofactor) One-Pass Diffie-Hellman, C(1e, 1s, ECC CDH) Scheme
This section describes the One-Pass Diffie-Hellman scheme. Assurance of secure key
establishment using this scheme can only be obtained when the assumptions in Section 6.2.2
are true. In particular, it is assumed that party U has obtained the static public key Qs,V ofparty V.
In this scheme, each party has different actions, which are presented separately below.
However, note that parties U and V must use identical orderings of the bit strings that are
input to the key-derivation method.
Party U shall execute the following actions to a) establish a shared secret value Z with party
V, and b) derive secret keying material from Z.
Actions: Party U generates a shared secret and derives secret keying material as follows:
1. Generate an ephemeral key pair (de,U, Qe,U) from the domain parameters D as specified
in Section 5.6.1.2. Send the public key Qe,U to party V.
2. Use the ECC CDH primitive in Section 5.7.1.2 to derive a shared secret Z from theset of domain parameters D, party U’s ephemeral private key de,U, and party V’s static
public key Qs,V. If this call to the ECC CDH primitive outputs an error indicator,
destroy the ephemeral private key de,U, and destroy the results of all intermediate
99

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

calculations used in the attempted computation of Z; then output an error indicator,and exit this process without performing the remaining actions.
3. Use the agreed-upon key-derivation method to derive secret keying material with thespecified length from the shared secret value Z and other input (see Section 5.8). If
the key-derivation method outputs an error indicator, destroy all copies of Z and theephemeral private key de,U; then output an error indicator, and exit this process
without performing the remaining actions.
4. Destroy de,U and all copies of the shared secret Z.
5. Output the derived keying material.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Output: The derived keying material or an error indicator.
Party V shall execute the following actions to a) establish a shared secret value Z with party
U, and b) derive secret keying material from Z.
Actions: Party V derives secret keying material as follows:
1. Receive an ephemeral public key Qe,U (purportedly) from party U. If Qe,U is notreceived, then output an error indicator, and exit this process without performing theremaining actions.
2. Verify that Qe,U is a valid ephemeral public key for the parameters D as specified in
Section 5.6.2.3. If assurance of public key validity cannot be obtained, then output anerror indicator, and exit without performing the remaining actions.
3. Use the ECC CDH primitive in Section 5.7.1.2 to derive a shared secret Z from theset of domain parameters D, party V’s static private key ds,V, and party U’s ephemeral
public key Qe,U. If this call to the ECC CDH primitive outputs an error indicator,
destroy the results of all intermediate calculations used in the attempted computationof Z; then output an error indicator, and exit this process without performing theremaining actions.
4. Use the agreed-upon key-derivation method to derive secret keying material with thespecified length from the shared secret value Z and other input (see Section 5.8). If
the key-derivation method outputs an error indicator, destroy all copies of Z; thenoutput an error indicator, and exit this process without performing the remaining
action.
6. Destroy all copies of the shared secret Z and output the derived keying material.
Output: The derived keying material or an error indicator.
Note: Key confirmation can be incorporated into this scheme. See Section 6.2.2.3 fordetails.
The One-Pass Diffie-Hellman is summarized in Table 20.

100

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

Table 20: One-pass Diffie-Hellman key-agreement scheme summary
Party U
Domainparameters
Static data
Ephemeral data

Party V(q, FR, a, b{, SEED}, G, n, h)(q, FR, a, b{, SEED}, G, n, h)

N/AStatic private key ds,VStatic public key Qs,V

Ephemeral private key de,U

N/AThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Ephemeral public key Qe,U
Computation

Derive secretkeying material

Compute Z by calling ECC CDH Compute Z by calling ECC CDH
using de,U and Qs,V
using ds,V and Qe,U
1. Compute
DerivedKeyingMaterial

1. Compute
DerivedKeyingMaterial

2. Destroy Z

2. Destroy Z

6.2.2.3 Incorporating Key Confirmation into a C(1e, 1s) Scheme
The subsection that follows illustrates how to incorporate key confirmation (as described in
Section 5.9) into the C(1e, 1s) key-agreement schemes described above. Note that only
unilateral key confirmation from party V to party U is specified, since only party V has astatic key pair that is used in the key-establishment process.
The flow depiction separates the key-establishment flow from the key-confirmation flow.
The depiction and accompanying discussion presumes that the assumptions of the scheme
have been satisfied, that the key-agreement transaction has proceeded successfully throughkey derivation, and that the received MacTag is successfully verified as specified in Section
5.2.2.
6.2.2.3.1 C(1e, 1s) Scheme with Unilateral Key Confirmation Provided by Party V to
Party U

Figure_13 depicts a typical flow for a C(1e, 1s) scheme with unilateral key confirmationfrom party V to party U. In this scenario, party V and party U assume the roles of the keyconfirmation provider and recipient, respectively. The successful completion of the keyconfirmation process provides party U with a) assurance that party V has derived the same
secret Z value, and b) assurance that party V has actively participated in the process.

101

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

UV
V’s Static Public Key

U’s Ephemeral Public Key

U obtains V’s static
public key
U sends an ephemeral
public key

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

MacTagVV’s key-confirmation

Figure 13: C(1e, 1s) scheme with unilateral key confirmation from party V to party U
To provide (and receive) key confirmation (as described in Section 5.9.1), both parties set
EphemDataV = Null, and EphemDataU = EphemPubKeyU.
Party V provides MacTagV to party U (as specified in Section 5.9.1, with P = V and R = U),
where MacTagV is computed (as specified in Section 5.2.1) using
MacDataV = “KC_1_V” || IDV || IDU || Null || EphemPubKeyU {|| TextV}.
Party U (the key-confirmation recipient) uses the same format for MacDataV to compute its
own version of MacTagV and then verifies that the newly computed MacTag matches thevalue provided by V.
Party V shall destroy its copy of MacKey immediately after computing MacTagV. Party U
shall immediately destroy its copy of MacKey after determining whether or not the received
and newly computed MacTagV values match. If they do not match, then party U shall also
destroy the KeyData portion of the DerivedKeyingMaterial (see Section 5.9.1) and notify
party V that MacTagV could not be verified. In this case, party V shall also destroy the
KeyData portion of the DerivedKeyingMaterial.
6.3

C(0e, 2s) Schemes

In this category, the parties use only static key pairs. Each party obtains the other party’s
static public key. A nonce, NonceU, is sent by party U to party V to ensure that the derived
keying material is different for each key-establishment transaction. This would beaccomplished by including (a copy of) NonceU in the OtherInput provided to the KDM, aspart of the FixedInfo (see Section 5.8). The parties calculate the shared secret using their own
static private key and the other party’s static public key. Secret keying material is derived
using the key-derivation method, the shared secret, and the nonce (see Figure 14).
102

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

UV
U’s Static Public Key
V’s Static Public Key

Obtain static public
keysThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

NonceUU sends a nonce

Figure 14: C(0e, 2s) schemes: each party contributes only a static key pair
Assumptions: In order to execute a C(0e, 2s) key-establishment scheme in compliance withthis Recommendation, the following assumptions shall be true.
1. Each party has an authentic copy of the same set of domain parameters, D. These
parameters are either approved for use in the intended application (see Section
5.5.1). For FFC schemes, D = (p, q, g{, SEED, counter}); for ECC schemes, D = (q,FR, a, b{, SEED}, G, n, h). Furthermore, each party has assurance of the validity ofthese domain parameters as specified in Section 5.5.2.
2. Each party has been designated as the owner of a static key pair that was generated
as specified in Section 5.6.1 using the set of domain parameters, D. For FFC schemes,
the static key pair is (x, y); for ECC schemes, the static key pair is (ds, Qs). Each party
has obtained assurance of the validity of its own static public key as specified in
Section 5.6.2.1.3. Each party has obtained assurance of its possession of the correct
value for its own private key as specified in Section 5.6.2.1.5.
3. The parties have agreed upon an approved key-derivation method (see Section 5.8),
as well as an approved algorithm used with the method (e.g., a hash function) andother associated parameters to be used. In addition, the parties have agreed on theform of the nonce (see Section 5.4), which should be a random nonce.
4. If key confirmation is used, the parties have also agreed upon an approved MAC andassociated parameters, including the lengths of MacKey and MacTag (see Section
5.9.3). If party V provides key confirmation to party U, the parties have agreed upon
the form of NonceV, which should be a random nonce.
5. Prior to or during the key-agreement process, each party receives the other party’s
static public key in a trusted manner (e.g., from a certificate signed by a trusted CA
or directly from the other party, who is trusted by the recipient). Each party has
obtained assurance of the validity of the other party’s static public key as specified in
Section 5.6.2.2.1.
103

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

6. The recipient of a static public key has obtained assurance that its (claimed) owner is(or was) in possession of the corresponding static private key, as specified in Section
5.6.2.2.3.
7. When an identifier is used to label a party during the key-agreement process, that
identifier has a trusted association with that party’s static public key. (In other words,
whenever both the identifier and static public key of one participant are employed in
the key-agreement process, they are associated in a manner that is trusted by the otherparticipant.) When an identifier is used to label a party during the key-agreement
process, both parties are aware of the particular identifier employed for that purpose.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

6.3.1 dhStatic, C(0e, 2s, FFC DH) Scheme
This section describes the dhStatic scheme. Assurance of secure key establishment using thisscheme can only be obtained when the assumptions in Section 6.3 are true. In particular, it
is assumed that party U has obtained the static public key yV of party V, and party V has
obtained the static public key yU of party U.
In this scheme, each party has different actions, which are presented separately below.
However, note that parties U and V must use identical orderings of the bit strings that are
input to the key-derivation method.
Party U shall execute the following actions to a) establish a shared secret value Z with party
V, and b) derive secret keying material from Z.
Actions: Party U generates a shared secret and derives secret keying material as follows:
1. Obtain a nonce, NonceU (see Section 5.4). Send NonceU to party V.
2. Use the FFC DH primitive in Section 5.7.1.1 to derive a shared secret Z from the setof domain parameters D, party U’s static private key xU, and party V’s static public
key yV. If the call to the FFC DH primitive outputs an error indicator, destroy NonceU,and destroy the results of all intermediate calculations used in the attempted
computation of Z; then output an error indicator, and exit this process without
performing the remaining actions.
3. Use the agreed-upon key-derivation method to derive secret keying material with thespecified length from the shared secret value Z, NonceU and other input (see Section
5.8). If the key-derivation method outputs an error indicator, destroy all copies of Z;
then output an error indicator, and exit this process without performing the remaining
actions.
4. Destroy all copies of the shared secret Z and output the derived keying material.
Output: The derived keying material bits or an error indicator.
Party V shall execute the following actions to a) establish a shared secret value Z with party
U, and b) derive secret keying material from Z.
Actions: Party V derives secret keying material as follows:
1. Obtain party U’s nonce, NonceU, from party U. If NonceU is not available, then output
an error indicator, and exit this process without performing the remaining actions.
104

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

2. Use the FFC DH primitive in Section 5.7.1.1 to derive a shared secret from the set of
domain parameters D, party V’s static private key xV, and party U’s static public key
yU. If the call to the FFC DH primitive outputs an error indicator, destroy the resultsof all intermediate calculations used in the attempted computation of Z; then output
an error indicator, and exit this process without performing the remaining actions.
3. Use the agreed-upon key-derivation method to derive secret keying material with thespecified length from the shared secret value Z, NonceU, and other input (see Section
5.8). If the key-derivation method outputs an error indicator, destroy all copies of Z;
then output an error indicator, and exit this process without performing the remaining
action.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

4. Destroy all copies of the shared secret Z and output the derived keying material.
Output: The derived keying material or an error indicator.
Note: Key confirmation can be incorporated into this scheme. See Section 6.3.3 for details.
dhStatic is summarized in Table 21.
Table 21: dhStatic key-agreement scheme summary
Party U
Domainparameters
Static data
Ephemeral
data
Computation

Party V(p, q, g{, SEED, counter})(p, q, g{, SEED, counter})

Static private key xU

Static private key xV

Static public key yU

Static public key yV

NonceU
Compute Z by calling FFC DH Compute Z by calling FFC DH
using xU, and yV
using xV, and yU

1. Compute
DerivedKeyingMaterial using
Derive secret
Z and NonceU
keying material
2. Destroy Z

1. Compute
DerivedKeyingMaterial using
Z and NonceU
2. Destroy Z

6.3.2 (Cofactor) Static Unified Model, C(0e, 2s, ECC CDH) Scheme
This section describes the Static Unified Model scheme. Assurance of secure key
establishment using this scheme can only be obtained when the assumptions in Section 6.3
are true. In particular, it is assumed that party U has obtained the static public key Qs,V ofparty V, and party V has obtained the static public key Qs,U of party U.

105

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

In this scheme, each party has different actions, which are presented separately below.
However, note that parties U and V must use identical orderings of the bit strings that are
input to the key-derivation method.
Party U shall execute the following actions to a) establish a shared secret value Z with party
V, and b) derive secret keying material from Z.
Actions: Party U generates a shared secret and derives secret keying material as follows:
1. Obtain a nonce, NonceU (see Section 5.4). Send NonceU to party V.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

2. Use the ECC CDH primitive in Section 5.7.1.2 to derive a shared secret Z from theset of domain parameters D, party U’s static private key ds,U, and party V’s static
public key Qs,V. If the call to the ECC CDH primitive outputs an error indicator,
destroy the results of all intermediate calculations used in the attempted computationof Z; then output an error indicator, and exit this process without performing theremaining actions.
3. Use the agreed-upon key-derivation method to derive secret keying material with thespecified length from the shared secret value Z, NonceU, and other input (see Section
5.8). If the key-derivation method outputs an error indicator, destroy all copies of Z;
then output an error indicator, and exit this process without performing the remaining
actions.
4. Destroy NonceU and all copies of the shared secret Z.
5. Output the derived keying material.
Output: The derived keying material or an error indicator.
Party V shall execute the following actions to a) establish a shared secret value Z, with party
U, and b) derive secret keying material from Z.
Actions: Party V derives secret keying material as follows:
1. Obtain party U’s nonce, NonceU, from party U. If NonceU is not available, then output
an error indicator, and exit this process without performing the remaining actions.
2. Use the ECC CDH primitive in Section 5.7.1.2 to derive a shared secret Z from theset of domain parameters D, party V’s static private key ds,V, and party U’s static
public key Qs,U. If the call to the ECC CDH primitive outputs an error indicator,
destroy the results of all intermediate calculations used in the attempted computationof Z; then output an error indicator, and exit this process without performing theremaining actions.
3. Use the agreed-upon key-derivation method to derive secret keying material with thespecified length from the shared secret value Z, NonceU, and other input (see Section
5.8). If the key-derivation method outputs an error indicator, destroy all copies of Z;
then output an error indicator, and exit this process without performing the remaining
action.
4. Destroy all copies of the shared secret Z and output the derived keying material.
Output: The derived keying material or an error indicator.
106

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

Note: Key confirmation can be incorporated into this scheme. See Section 6.3.3 for details.
Static Unified Model is summarized in Table 22.
Table 22: Static unified model key-agreement scheme summary
Party U
Domainparameters
Static data

Party VThis publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3(q, FR, a, b{, SEED}, G, n, h)(q, FR, a, b{, SEED}, G, n, h)

Static private key ds,U

Static private key ds,VStatic public key Qs,U

Static public key Qs,V

Ephemeral data

NonceU

Computation

Compute Z by calling ECC CDH Compute Z by calling ECC
using ds,U, and Qs,V
CDH using ds,V, and Qs,U

Derive secretkeying material

1. Compute DerivedKeyingMaterial 1. Computeusing NonceU
DerivedKeyingMaterialusing NonceU
2. Destroy Z
2. Destroy Z

6.3.3 Incorporating Key Confirmation into a C(0e, 2s) Scheme
The subsections that follow illustrate how to incorporate key confirmation (as described in
Section 5.9) into the C(0e, 2s) key-agreement schemes described above. Note that party V
cannot act as a key confirmation unless a nonce (NonceV) is provided by party V to party U
and is used (in addition to the shared secret Z) as input to the key-derivation method
employed by the scheme. This would be accomplished by including (a copy of) NonceV in
the OtherInput provided to the KDM, as part of the FixedInfo (see Section 5.8), in addition
to using (a copy of) NonceV as the EphemDataV employed in the MacTag computations for
key confirmation.
The flow depictions separate the key-establishment flow from the key-confirmation flow.
The depictions and accompanying discussions presume that the assumptions of the scheme
have been satisfied, that the key-agreement transaction has proceeded successfully throughkey derivation, and that the received MacTags are successfully verified as specified in
Section 5.2.2.
6.3.3.1 C(0e, 2s) Scheme with Unilateral Key Confirmation Provided by Party
U to Party V
Figure_15 depicts a typical flow for a C(0e, 2s) scheme with unilateral key confirmationfrom party U to party V. In this scenario, party U and party V assume the roles of keyconfirmation provider and recipient, respectively. A nonce (NonceV) shall be provided byparty V to party U and used (in addition to the shared secret Z and the nonce provided by107

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

party U) as input to the key-derivation method employed by the scheme. NonceV is also usedas the EphemDataV during MacTag computations. The successful completion of the keyconfirmation process provides party V with assurance that party U has derived the same
secret Z value. If NonceV is a random nonce, then party V also obtains assurance that party
U has actively participated in the process; see Section 5.4 for a discussion of the length andsecurity strength required for the nonce.

U

V

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

U’s Static Public Key
V’s Static Public Key
NonceU

Obtain static
public keys

U sends a nonce

NonceVV sends a nonce
MacTagU

U’s key confirmation

Figure 15: C(0e, 2s) scheme with unilateral key confirmation from party U to party V
To provide (and receive) key confirmation (as described in Section 5.9.1), party U (and partyV) setEphemDataU = NonceU, and EphemDataV = NonceV.
Party U provides MacTagU to party V (as specified in Section 5.9.1, with P = U and R = V),
where MacTagU is computed (as specified in Section 5.2.1) using
MacDataU = “KC_1_U” || IDU || IDV || NonceU || NonceV {|| TextU}.
Party V (the key-confirmation recipient) uses the same format for MacDataU to compute its
own version of MacTagU and then verifies that the newly computed MacTag matches thevalue provided by party U.
Party U shall destroy its copy of MacKey immediately after computing MacTagU. Party V
shall immediately destroy its copy of MacKey after determining whether or not the received
and newly computed MacTagU values match. If they do not match, then party V shall also
destroy the KeyData portion of the DerivedKeyingMaterial (see Section 5.9.1) and notify
party U that MacTagU could not be verified. In this case, party U shall also destroy the
KeyData portion of the DerivedKeyingMaterial.
108

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

6.3.3.2 C(0e, 2s) Scheme with Unilateral Key Confirmation Provided by Party
V to Party U
Figure_16 depicts a typical flow for a C(0e, 2s) scheme with unilateral key confirmationfrom party V to party U. In this situation, party V and party U assume the roles of keyconfirmation provider and recipient, respectively. The successful completion of the keyconfirmation process provides party U with assurance that party V has derived the same
secret Z value; if NonceU is a random nonce, then party U also obtains assurance that party
V has actively participated in the process; see Section 5.4 for a discussion of the length andsecurity strength required for the nonce.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

UV
U’s Static Public Key
V’s Static Public Key

Obtain static public
keys

NonceUU sends a nonce
MacTagVV’s key confirmation

Figure 16: C(0e, 2s) scheme with unilateral key confirmation from party V to party U
To provide (and receive) key confirmation (as described in Section 5.9.1), both parties set
EphemDataV = Null, and EphemDataU = NonceU.
Party V provides MacTagV to party U (as specified in 5.9.1, with P = V and R = U), where
MacTagV is computed (as specified in Section 5.2.1) using
MacDataV = “KC_1_V” || IDV || IDU || Null || NonceU {|| TextV}.
Party U (the key-confirmation recipient) uses the same format for MacDataV to compute its
own version of MacTagV, and then verifies that the newly computed MacTag matches thevalue provided by party V.
Party V shall destroy its copy of MacKey immediately after computing MacTagV. Party U
shall immediately destroy its copy of MacKey after determining whether or not thereceived and newly computed MacTagV values match. If they do not match, then party U
shall also destroy the KeyData portion of the DerivedKeyingMaterial (see Section 5.9.1)
and notify party V that MacTagV could not be verified. In this case, party V shall also
destroy the KeyData portion of the DerivedKeyingMaterial.

109

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

6.3.3.3 C(0e, 2s) Scheme with Bilateral Key Confirmation

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Figure_17 depicts a typical flow for a C(0e, 2s) scheme with bilateral key confirmation. In
this method, party U and party V assume the roles of both the provider and the recipient inorder to obtain bilateral key confirmation. A nonce (NonceV) shall be provided by party V toparty U and used (in addition to the shared secret Z and the nonce, NonceU, provided by partyU) as input to the key-derivation method employed by the scheme. NonceV is also used as
the EphemDataV during MacTag computations. The successful completion of the keyconfirmation process provides each party with assurance that the other party has derived thesame secret Z value. If NonceU is a random nonce, then party U obtains assurance that party
V has actively participated in the process; if NonceV is a random nonce, then party V obtains
assurance that party U has actively participated in the process. See Section 5.4 for a
discussion about the length and security strength required for the nonce.

UV
U’s Static Public Key
V’s Static Public Key

Obtain static public
keys

NonceUU sends a nonce

NonceV, MacTagV
V sends a nonce with
key-confirmation
MacTagU

U’s key-confirmation

Figure 17: C(0e, 2s) scheme with bilateral key confirmation
To provide bilateral key confirmation (as described in Section 5.9.2), party U and party V
exchange and verify MacTags that have been computed (as specified in Section 5.2.1) using
EphemDataU = NonceU, and EphemDataV = NonceV.
Party V provides MacTagV to party U (as specified in Sections 5.9.1 and 5.9.2, with P = V
and R = U); MacTagV is computed by party V (and verified by party U) using
MacDataV = “KC_2_V” || IDV || IDU || NonceV || NonceU {|| TextV}.
Party U provides MacTagU to party V (as specified in Sections 5.9.1 and 5.9.2, with P = U
and R = V); MacTagU is computed by party U (and verified by party V) using
MacDataU = “KC_2_U” || IDU || IDV || NonceU || NonceV {|| TextU}.
110

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

Note that in Figure 17, party V’s nonce (NonceV ) and the MacTag (MacTagV) are depicted
as being sent in the same message (to reduce the number of passes in the combined keyagreement/key-confirmation process). They can also be sent in other orders andcombinations (as long as NonceU and NonceV are available to generate and verify both MACtags).

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Each party shall destroy its copy of MacKey immediately after 1) using it to generate a MAC
tag to be sent to the other party and 2) determining whether or not the MAC tag received
from the other party matches the MAC tag that it computed. However, if either party is notable to verify the received MAC tag, that party shall also destroy the KeyData portion of the
DerivedKeyingMaterial (see Section 5.9.1) and notify the other party of the failure. In thiscase, the other party shall destroy both the MacKey (if it has not already done so) as well as
the KeyData portion of the DerivedKeyingMaterial.

111

NIST SP 800-56A Rev. 3

7.

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

Rationale for Selecting a Specific Scheme

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

The subsections that follow present possible justifications for selecting schemes from eachsubcategory, C(ie, js). The proffered rationales are intended to provide the user and/or
developer with some information that may help when deciding the key-agreement scheme to
be used. The rationales include brief discussions of basic security properties, but do notconstitute an in-depth analysis of all possible security properties of all schemes under all
adversary models. The specific security properties that are cited will depend on suchconsiderations as whether a static key is used, whether an ephemeral key is used, how theshared secret is calculated, and whether key confirmation can be incorporated into a scheme.
In general, the security properties cited for a subcategory of schemes are exhibited by eachscheme within that subcategory; when this is not the case, the exceptions are identified.
A scheme should not be chosen based solely on the number of security properties it may
possess. Rather, a scheme should be selected based on how well the scheme fulfills system
requirements. For instance, if messages are exchanged over a large-scale network where eachexchange consumes a considerable amount of time, a scheme with fewer exchanges during
a single key-agreement transaction might be preferable to a scheme with more exchanges,
even though the latter may possess more security benefits. It is important to keep in mind
that a key-agreement scheme may be a component of a larger protocol that offers additional
security-related assurances beyond those provided by the key-agreement scheme alone. For
example, the protocol may include specific features that limit opportunities for accidental or
intentional misuse of the key-agreement component of the protocol. Protocols, per se, are notspecified in this Recommendation.
Important Note: In order to provide concise descriptions of security properties possessedby the various schemes, it is necessary to make some assumptions concerning the format andtype of data that is used as input during key derivation. These assumptions are made solely
for the purposes of Sections 7.1 through 7.5; they are not intended to preclude the options
specified elsewhere in this Recommendation. When discussing the security properties of a
subcategory of schemes, it is assumed that the FixedInfo input to a key-derivation method
employed during a particular key-agreement transaction uses either the concatenation format
or the ASN.1 format (see Sections 5.8.2.1.1 and 5.8.2.1.2). It is also assumed that FixedInfo
includes sufficiently specific identifiers for the participants in the transaction, an identifier
for the key-agreement scheme being used during the transaction, and additional input (e.g.,a nonce, ephemeral public key, and/or session identifier) that may provide assurance to one
or both participants that the derived keying material will reflect the specific context in which
the transaction occurs (see Section 5.8.2 and Appendix B for further discussion concerning
context-specific information that may be appropriate for inclusion in FixedInfo). In general,
FixedInfo may include pre-shared secrets, but that is not assumed to be the case in theanalysis of security properties that follows. In cases where an approved extraction-thenexpansion key-derivation procedure is employed (see SP 800-56C), it is assumed that thisFixedInfo is used as the Context input during the key-expansion step. Finally, it is assumed
that all required nonces employed during the transaction are random nonces that contain acomponent consisting of a random bit string formed in accordance with the recommendationsof Section 5.4.
112

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

7.1 Rationale for Choosing a C(2e, 2s) Scheme
These schemes require each participant to own a static key pair that is used in their keyagreement transaction. Static key pairs can provide the participants with some level ofassurance that they have correctly identified the party with whom they will be establishingkeying material if the transaction is successfully completed.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

In the case of a key-agreement transaction based on the Full Unified model or dhHybrid1
scheme, each participant has assurance that no unintended entity (i.e., no entity other thanthe owners of the static key pairs involved in the transaction) could employ a Diffie-Hellman
primitive (see Section 5.7.1) to compute Zs, the static component of the shared secret Z
without knowledge of one of the static private keys employed during the transaction. Absent
the compromise of Zs or one of those static private keys, each participant can be confident ofcorrectly identifying the other participant in the key-establishment transaction. The level ofconfidence is commensurate with the specificity of the identifiers that are associated with thestatic public keys (and are used as input during the key-derivation process), the degree oftrust in the association between those identifiers and static public keys, the assurance ofvalidity of the domain parameters and static public keys, and the availability of evidence thatthe keying material has been correctly derived.
Similarly, in the case of a key-agreement transaction based on Full MQV or MQV2, eachparticipant has assurance that no unintended entity could use a DLC primitive to computethe shared secret Z without knowledge of either a static private key or a private-keydependent implicit signature employed during the transaction. (The term “implicit signature”
refers to those quantities denoted SA and implicitsigA in the descriptions of the MQVprimitives in Section 5.7.2.1 and Section 5.7.2.3, respectively.) Absent the compromise of Z,a static private key, or an implicit signature, each participant can be confident of correctly
identifying the other participant in the key-establishment transaction. As above, the level ofconfidence is commensurate with the specificity of the identifiers that are associated with thestatic public keys (and are used as input during the key-derivation process), the degree oftrust in the association between those identifiers and static public keys, the assurance ofvalidity of the domain parameters and static public keys, and the availability of evidence thatthe keying material has been correctly derived.
These schemes also require each participant to generate an ephemeral key pair that is usedin their transaction, providing each participant with assurance that the resulting shared secret(and the keying material derived from it) will vary from one of their C(2e, 2s) transactions
to the next.
Each participant in a C(2e, 2s) transaction has assurance that the value of the resulting sharedsecret Z will not be completely revealed to an adversary who is able to compromise (only)
their static private keys at some time after the transaction is completed. (The adversary
would, however, be able to compute Zs, the static component of the shared secret, if the keyagreement transaction was based on the Full Unified model or dhHybrid1 scheme.) Thisassurance is commensurate with the confidence that a participant has that neither of theephemeral private keys employed in the transaction will be compromised. By generating
their ephemeral key pairs as close to the time of use as possible and destroying the ephemeral
private keys after their use, the participants reduce the risk of such a compromise.
113

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

If a particular entity’s static private key is acquired by an adversary, then the adversary could
masquerade as that entity while engaging in any C(2e, 2s) key-agreement transaction that
permits the use of the compromised key pair. If an MQV scheme (MQV2 or Full MQV) will
be employed during a transaction with an adversary who is in possession of a compromised
static private key (or a compromised implicit signature corresponding to that static privatekey), the adversary is limited to masquerading as the owner of the compromised key pair (oras the owner of the static key pair corresponding to the compromised implicit signature). The
use of the Full Unified model or dhHybrid1 scheme, however, offers the adversary additional
opportunities for masquerading: If an adversary compromises an entity’s static private key,then the adversary may be able to impersonate any other entity during a Full Unified modelor dhHybrid1-based key-agreement transaction with that entity. Also, the compromise of Zs,
the static component of a shared secret that was (or would be) formed by two parties using
the Full Unified Model or dhHybrid1 scheme will permit an adversary to masquerade as
either party to the other party in key-agreement transactions that rely on the same schemeand the same two static key pairs.
Key confirmation can be provided in either or both directions as part of a C(2e, 2s) schemeby using the methods specified in Section 6.1.1.5. This allows the key confirmation recipient
to obtain assurance that the key-confirmation provider has possession of the MacKey derived
from the shared secret Z and has used it with the appropriate MacData to compute thereceived MacTag. In the absence of some compromise of secret information (e.g., a staticprivate key or a static component of Z), a key-confirmation recipient can obtain assurance
that the appropriate identifier has been used to label the key-confirmation provider and thatthe provider is the owner of the static public key associated with that identifier. A keyconfirmation recipient can also receive assurance of active (and successful) participation by
the key-confirmation provider in the key-agreement transaction.
7.2 Rationale for Choosing a C(2e, 0s) Scheme
These schemes require each participant to generate an ephemeral key pair that is used in their
key-agreement transaction. No static key pairs are employed. Because the ephemeral private
keys used in the computation of their shared secret are destroyed immediately after use, theseschemes offer assurance to each party that the shared secret Z computed during a legitimateC(2e, 0s) transaction (i.e., one that involves two honest parties and is not influenced by anadversary) is protected against any compromise of shared secrets and/or private keys
associated with other (prior or future) transactions.
Unlike a static public key, which is assumed to have a trusted association with an identifier
for its owner, there is no assumption of a trusted association between an ephemeral public
key and an identifier. Thus, these schemes, by themselves, offer no assurance to either partyof the accuracy of any identifier that may be used to label the entity with whom they haveestablished a shared secret. The use of C(2e, 0s) schemes may be appropriate in applications
where any trusted association desired/required between an identifier and an ephemeral public
key is enforced by methods external to the scheme (e.g., in the protocol incorporating the
key-agreement scheme).
This Recommendation does not specify the incorporation of key confirmation in a C(2e, 0s)
scheme.
114

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

7.3 Rationale for Choosing a C(1e, 2s) Scheme
These schemes require each participant to own a static key pair that is used in their keyagreement transaction; in addition, the participant acting as party U is required to generate
and use an ephemeral key pair. Different assurances are provided to the participants by theutilization of a C(1e, 2s) scheme, depending upon which one acts as party U and which one
acts as party V.
The use of static key pairs in the key-agreement transaction can provide the participants withsome level of assurance that they have correctly identified the party with whom they will beestablishing keying material if the transaction is successfully completed.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

In the case of a transaction based on the One-Pass Unified model or dhHybridOneflow
scheme, each participant has assurance that no unintended entity (i.e., no entity other thanthe owners of the static key pairs involved in the key-establishment transaction) could
employ a Diffie-Hellman primitive (see Section 5.7.1) to compute Zs, the static componentof the shared secret Z, without knowledge of one of the static private keys employed during
the transaction. Absent the compromise of Zs or one of those static private keys, eachparticipant can be confident of correctly identifying the other participant in the keyestablishment transaction. The level of confidence is commensurate with the specificity of
the identifiers that are associated with the static public keys (and are used as input during the
key-derivation process), the degree of trust in the association between those identifiers andstatic public keys, the assurance of validity of the domain parameters and static public keys,
and the availability of evidence that the keying material has been correctly derived.
Similarly, in the case of a key-agreement transaction based on the One-Pass MQV or MQV1
scheme, each participant has assurance that no unintended entity could use a DLC primitive
to compute the shared secret Z without knowledge of either the static private key of one ofthe participants in the transaction or the private-key dependent implicit signature employedby party U during the transaction. (The term “implicit signature” refers to those quantities
denoted SA and implicitsigA in the descriptions of the MQV primitives in Section 5.7.2.1 andSection 5.7.2.3, respectively.) Absent the compromise of Z, a static private key, or party U’s
implicit signature, each participant can be confident of correctly identifying the otherparticipant in the key-establishment transaction. As above, the level of confidence iscommensurate with the specificity of the identifiers that are associated with the static publickeys (and are used as input during the key-derivation process), the degree of trust in theassociation between those identifiers and static public keys, the assurance of validity of thedomain parameters and static public keys, and the availability of evidence that the keying
material has been correctly derived.
Party U, whose ephemeral key pair is used in the computations, has assurance that theresulting shared secret will vary from one C(1e, 2s) transaction to the next such transaction
with the same party V. The participant acting as party V cannot obtain such assurance, in
general, since party V’s contribution to the computation of Z is static. Party V can, however,obtain assurance that the derived keying material will vary if, for example, party V
contributes a nonce that is used as input to the key-derivation method employed during thesetransactions (as is required when party V is a recipient in a key-confirmation process
performed as specified in this Recommendation). The assurance of freshness of the derived
115

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

keying material that can be obtained in this way by the participant acting as party V iscommensurate with the participant’s assurance that a different nonce will be contributed
during each such transaction.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

The compromise of the static private key used by party U does not, by itself, compromise
the shared secret computed during any legitimate C(1e, 2s) transaction (i.e., a transaction
involving two honest parties). Likewise, the compromise of only the ephemeral private key
used by party U would not compromise the shared secret Z for that transaction. However, thecompromise of an entity’s static private key may lead to the compromise of the shared secrets
computed during past, current, and future C(1e, 2s) transactions in which that entity acts asparty V (regardless of the static or ephemeral keys used by the entity acting as party U); tocompromise those shared secrets, the adversary must also acquire the public keys contributedby whomever acts as party U in those transactions.
If an adversary learns a particular entity’s static private key, then, in addition tomasquerading as that particular entity, the adversary may be able to impersonate any otherentity while acting as party U in a C(1e, 2s) transaction in which the owner of thecompromised static private key acts as party V. Similarly, the compromise of the static
component, Zs, of a shared secret formed by two entities using the One-Pass Unified Modelor dhHybrid1OneFlow scheme will permit an adversary to masquerade as either entity (while
acting as party U) to the other entity (acting as party V) in future key-agreement transactions
that rely on the same scheme and the same two static key pairs. If the MQV1 or One-Pass
MQV scheme will be employed during a key-agreement transaction with an adversary who
is in possession of a compromised implicit signature corresponding to a static private key,
the adversary may be able to masquerade as the owner of that static key pair while acting as
party U (provided that the static key pair is compatible with the domain parameters employedduring the transaction).
Key confirmation can be provided in either or both directions as part of a C(1e, 2s) schemeby using the methods specified in Section 6.2.1.5. This allows the key confirmation recipient
to obtain assurance that the key-confirmation provider has possession of the MacKey derived
from the shared secret Z and has used it with the appropriate MacData to compute thereceived MacTag. In the absence of a compromise of secret information (e.g., a static private
key or a static component of Z), a key-confirmation recipient can obtain assurance that theappropriate identifier has been used to label the key confirmation provider and that theprovider is the owner of the static public key associated with that identifier. A keyconfirmation recipient can also receive assurance of active (and successful) participation by
the key-confirmation provider in the key-agreement transaction.
7.4 Rationale for Choosing a C(1e, 1s) Scheme
In these schemes, the participant acting as party U is required to generate and use an
ephemeral key pair, while the participant acting as party V is required to own a static key
pair that is used in the key-agreement transaction. Different assurances are provided to theparticipants by the utilization of a C(1e, 1s) scheme, depending upon which one acts as party
U and which one acts as party V.

116

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

The use of a static public key attributed to party V can provide the participant acting as party
U with some level of assurance that he has correctly identified the party with whom he willbe establishing keying material if the transaction is successfully completed.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Whether the transaction is based on the One-Pass Diffie-Hellman or dhOneflow scheme, theparticipant acting as party U has assurance that no unintended entity (i.e., no entity other thanhimself and the owner of the static public key attributed to party V) could employ a DiffieHellman primitive (see Section 5.7.1) to compute the shared secret Z without knowledge of
one of the private keys employed during the transaction. Absent the compromise of Z or oneof those private keys, the participant acting as party U can be confident of correctly
identifying the other participant in the key-establishment transaction as the owner of thestatic public key attributed to party V. The level of confidence is commensurate with thespecificity of the identifier that is associated with the static public key attributed to party V(and is used as input during the key-derivation process), the degree of trust in the association
between that identifier and the static public key, the assurance of validity of the domain
parameters and static public key, and the availability of evidence that the keying material has
been correctly derived.
The participant acting as party V has no such assurance, in general, since he has no assurance
concerning the accuracy of any identifier that may be used to label party U (unless the
protocol using this scheme includes additional elements that establish a trusted association
between an identifier for party U and the ephemeral public key that party U contributes tothe transaction).
The participant acting as party U, whose ephemeral key pair is used in the computations, hasassurance that the resulting shared secret will vary from one C(1e, 1s) transaction to the next.
The participant acting as party V has no such assurance, since party V’s contribution to thecomputation of Z is static.
There is no assurance provided to either participant that the security of the shared secret isprotected against the compromise of a private key. A compromise of the ephemeral private
key used in a C(1e, 1s) transaction only compromises the shared secret resulting from thatparticular transaction (and by generating the ephemeral key pair as close to the time of use
as possible and destroying the ephemeral private key after its use, the participant acting as
party U reduces the risk of such a compromise). However, the compromise of an entity’s
static private key may lead to the compromise of shared secrets resulting from past, current,
and future C(1e, 1s) transactions in which that entity acts as party V (no matter what party
plays the role of party U); to compromise those shared secrets, the adversary must alsoacquire the ephemeral public keys contributed by whomever acts as party U in thosetransactions. In addition, if an adversary learns a particular entity’s static private key, theadversary may be able to impersonate that particular entity while acting as party V in a C(1e,1s) transaction that employs compatible domain parameters.
The participant acting as party V may provide key confirmation to party U as specified in
Section 6.2.2.3. This allows the participant acting as party U (who is the key confirmation
recipient) to obtain assurance that party V has possession of the MacKey derived from theshared secret Z and has used it with the appropriate MacData to compute the received
MacTag. In the absence of a compromise of secret information (e.g., a private key), the117

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

participant acting as party U can obtain assurance that the appropriate identifier has beenused to label party V, and that the participant acting as party V is indeed the owner of thestatic public key associated with that identifier. Under such circumstances, the participant
acting as party U can also receive assurance of the active (and successful) participation in
the key-agreement transaction by the owner of the static public key attributed to party V.
This Recommendation does not specify the incorporation of key confirmation from party U
to party V in a C(1e, 1s) scheme.
7.5 Rationale for Choosing a C(0e, 2s) Scheme
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

These schemes require each participant to own a static key pair that is used in their keyagreement transaction; in addition, the participant acting as party U is required to generate anonce, which is sent to party V and used (by both participants) as input to their chosen keyderivation method.
The use of static key pairs in the key-agreement transaction can provide the participants withsome level of assurance that they have correctly identified the party with whom they will beestablishing keying material if the transaction is successfully completed.
Whether the transaction is based on the Static Unified Model or dhStatic scheme, eachparticipant has assurance that no unintended entity (i.e., no entity other than the owners of
the static key pairs employed in the transaction) could employ a Diffie-Hellman primitive(see Section 5.7.1) to compute the static shared secret Z without knowledge of one of thestatic private keys employed during the transaction. Absent the compromise of Z or one ofthose static private keys, each participant can be confident of correctly identifying the otherparty in the key-establishment transaction. The level of confidence is commensurate with thespecificity of the identifiers that are associated with the static public keys (and are used as
input during the key-derivation process), the degree of trust in the association between those
identifiers and static public keys, the assurance of validity of the domain parameters andstatic public keys, and the availability of evidence that the keying material has been correctly
derived.
Although the value of Z is the same in all C(0e, 2s) key-establishment transactions between
the same two parties (as long as the two participants employ the same static key pairs), theparticipant acting as party U, whose (required) nonce is used in the key-derivation
computations, has assurance that the derived keying material will vary from one of theirC(0e, 2s) transactions to the next. In general, the participant acting as party V has no suchassurance – unless, for example, party V also contributes a nonce that is used as input to the
key-derivation method employed during the transaction (as is required when party V is arecipient of key confirmation performed as specified in this Recommendation). The
assurance of freshness of the derived keying material that can be obtained by a participant in
a C(0e, 2s) transaction is commensurate with the participant’s assurance that a different
nonce will be contributed during each such transaction.
If the static Z value formed by the two participants is ever compromised, then all of the
keying material derived in past, current, and future C(0e, 2s) key-agreement transactions
between these same two entities that employ these same static key pairs may be compromised
as well, since the same Z value is used to derive keying material in each instance. However,118

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

to compromise the keying material from a particular transaction, the adversary must alsoacquire (at least) the nonce contributed by the participant that acted as party U in thattransaction. The compromise of the static Z value may also permit an adversary tomasquerade as either entity to the other entity in future C(0e, 2s) key-agreement transactions.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

If a particular entity’s static private key is compromised, then shared secrets resulting fromcurrent, prior and future C(0e, 2s) transactions involving that entity’s static key pair may becompromised, irrespective of the role (whether party U or party V) played by thecompromised entity. Regardless of what entity acts in the other role when interacting withthe compromised entity, the adversary may be able to compute the shared secret Z andproceed to compromise the derived keying material, as described above. To complete theattack against a transaction, the adversary must acquire (at least) the static public key
contributed by the other entity participating in that transaction with the compromised entity,
as well as the nonce contributed by whichever entity acted as party U during the transaction.
Of course, if a static private key has been compromised by an adversary, then (if thecompromised key pair is of the type permitted by the scheme and domain parameters) theadversary may masquerade as the owner of the compromised static key pair in key-agreementtransactions with any other party. In addition, the adversary may masquerade as any entity(whether acting as party U or party V) while engaging in a C(0e, 2s) key-agreementtransaction with the owner of the compromised key pair.
Key confirmation can be provided in either or both directions as part of a C(0e, 2s) schemeby using the methods specified in Section 6.3.3.1. This allows the key confirmation recipient
to obtain assurance that the key-confirmation provider has possession of the MacKey derived
from the shared secret Z and has used it with the appropriate MacData to compute thereceived MacTag. In the absence of a compromise of private information (e.g., a static private
key or the static shared secret, Z), a key-confirmation recipient can obtain assurance that theappropriate identifier has been used to label the key-confirmation provider, and that theprovider is the owner of the static public key associated with that identifier. A keyconfirmation recipient can also receive assurance of active (and successful) participation by
the key-confirmation provider in the key-agreement transaction.
7.6 Summary of Assurances Associated with Key-Agreement Schemes
The security-related features discussed in the preceding subsections of Section 7 can besummarized in terms of the following types of assurance that may be obtained whenparticipating in a key-agreement transaction.
•

Implicit Key Authentication (IKA): Assurance obtained by one party in a keyagreement transaction that only a specifically identified entity (the intended second
party in that key-agreement transaction) could also derive the key(s) of interest.

•

Key Freshness (KF): Assurance obtained by one party in a key-agreementtransaction that keying material derived during that transaction is statisticallyindependent of the keying material derived during that party’s previous keyagreement transactions.

119

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3•

Forward Secrecy (FS): Assurance obtained by one party in a key-agreementtransaction that the keying material derived during that transaction is secure against
the future compromise of the static private key-agreement keys (if any) of theparticipants.

•

Key-Compromise Impersonation Resilience (K-CI): Assurance obtained by one
party in a key-agreement transaction that the compromise of that party’s static private
key-agreement key would not permit an adversary to impersonate the apparent
second party in the key-agreement transaction.

•

Key Confirmation (KC): Assurance obtained by one party in a key-agreementtransaction that a specifically identified entity (the intended second party in that keyagreement transaction) has correctly derived, and is able to use, the key(s) of interest.

Notes:A participant in a key-agreement transaction cannot hope to distinguish between theactions of another entity and the actions of those who share knowledge of that entity’s
private key-agreement key(s) and/or any other secret data sufficient for that entity’s
successful participation in a particular key-agreement transaction. In what follows,references to a “specifically identified entity” must be interpreted as an umbrella term
including all those who are legitimately in possession of that entity’s private key(s), etc.,
and are trusted to act on the entity’s behalf. Any assurance obtained with respect to theactions of a specifically identified entity is conditioned upon the assumption that theidentified entity’s relevant private/secret data has not been misused by a trusted party orcompromised by an adversary.
IKA assurance, as used in this Recommendation, does not address the potential
compromise of derived keying material because of misuse, mishandling, side-channel
leakage, etc.
Similarly, assurance of forward secrecy (FS), as defined in this Recommendation, does
not address problems that may arise from sources other than the compromise of staticprivate key-agreement keys. There can be, of course, other threats to the security ofderived keying material, such as the use of derived keys in cryptographic algorithms ordevices that have been compromised. Improper storage or transport of keying material,
the failure to prevent the leakage of sensitive information during computations involving
the derived keys, and/or inadequate methods for the timely destruction of sensitive data(including ephemeral private keys and the derived keys themselves) are just a few
examples of problems that could lead to an eventual compromise of keying material
derived during a particular transaction.
FS assurance is (trivially) obtained when using a C(2e, 0s) scheme in a key-agreementtransaction. The derived keying material is secure against any future compromise of staticprivate key-agreement keys because no such keys are employed by the participants. A
protocol may incorporate a C(2e, 0s) scheme as a means of securing its key-establishment
component against the possibility of a future compromise of various long-term
secret/private keys used (e.g., for authentication purposes) by protocol participants.

120

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

The notion of key-compromise impersonation resilience (K-CI), as defined in thisRecommendation, is not applicable to C(2e, 0s) schemes, because neither party employsa static private key-agreement key that an adversary might acquire and employ in amasquerade attempt. K-CI assurance is not applicable to C(1e, 1s) schemes either. Only
party V has a static key pair, and whether the static private key is compromised or not,the use of (only) an ephemeral key pair by party U cannot provide party V with assuranceof the accuracy of any identifier that may be associated with party U. The notion of keycompromise impersonation resilience is only applicable to schemes in which each party
is expected to employ a static private key-agreement key.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

In the definition of KC assurance, this Recommendation’s requirement that it be a
specifically identified entity who demonstrates the ability to use (some portion of) the
derived keying material is a stricter condition than is sometimes found in the literature.
In this Recommendation, KC assurance presupposes IKA assurance with respect to (atleast) the MAC key used in the key-confirmation computations.
KC assurance can be obtained in accordance with this Recommendation by incorporating
key-confirmation into a key-agreement scheme in which the KC provider is expected touse a static private key-agreement key, and the KC recipient is expected to contribute
ephemeral data that affects the values of both the derived MacKey and the MacData used
to compute a key-confirmation MacTag.
The following table shows which types of assurance can be obtained by which participantsin a key-agreement transaction by using appropriately implemented schemes from theindicated scheme subcategories. The previous assumptions in Section 7 concerning theformat and content of FixedInfo, the specificity of identifiers bound to static public keys, therandomness of nonces, etc., still hold.
Table 23: Summary of assurances
SchemeSubcategory

Sections

Assurance that can be Obtained by the Indicated Parties
IKA
KF
FS
K-CI
KC

C(2e, 2s)6.1.1, 7.1

U&V

U&V

U&V

U* & V*

U&V

C(2e, 0s)6.1.2, 7.2

–

U&V

U&V

N/A

–

C(1e, 2s)6.2.1, 7.3

U&V

U & V**–U

U&V

C(1e, 1s)6.2.2, 7.4

U

U

–

N/A

U

C(0e, 2s)6.3, 7.5

U&V

U & V**––

U & V*** K-CI assurance can be obtained using a C(2e, 2s) scheme only when the key-agreement
scheme employed is either C(2e, 2s, FFC MQV) or C(2e, 2s, ECC MQV).
** The indicated type of assurance can be obtained by party V only if party V exercises theoption of contributing a random nonce that is employed in key derivation and (when desired)
key confirmation, as specified in this Recommendation.
121

NIST SP 800-56A Rev. 3

8.

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

Key Recovery

For some applications, the secret keying material used to protect data may need to be
recovered (for example, if the normal reference copy of the secret keying material is lost or
corrupted). In this case, either the secret keying material or sufficient information toreconstruct the secret keying material needs to be available (for example, the keys, domain
parameters and other inputs to the scheme used to perform the key-establishment process).
Keys used during the key-establishment process shall be handled in accordance with thefollowing:
1. A static key pair may be saved.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

2. An ephemeral public key may be saved.
3. An ephemeral private key shall be destroyed after use and, therefore, shall not berecoverable.
4. A symmetric key may be saved.
Note: This implies that keys derived from schemes where both parties generate ephemeral
key pairs (i.e., the C(2e, 2s) and C(2e, 0s) schemes) cannot be made recoverable byreconstruction of the secret keying material by parties requiring the ephemeral private key intheir calculations. For those schemes where only party U generates an ephemeral key pair(i.e., the C(1e, 2s) and C(1e, 1s schemes), only party V can recover the secret keying material
by reconstruction.
General guidance on key recovery and the protections required for each type of key isprovided in SP 800-57.

122

NIST SP 800-56A Rev. 3

9.

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

Implementation Validation

When the NIST Cryptographic Algorithm Validation Program (CAVP) and the
Cryptographic Module Validation Program (CMVP) have established a validation program
for this Recommendation, a vendor shall have its implementation tested and validated by the
CAVP and CMVP to claim conformance to this Recommendation. Information on the CAVP
is available at https://csrc.nist.gov/Projects/Cryptographic-Algorithm-Validation-Program;
information on the CMVP is available at https://csrc.nist.gov/projects/cryptographicmodule-validation-program.
An implementation claiming conformance to this Recommendation shall include one ormore of the following capabilities:
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3•

Domain parameter generation or selection as specified in Section 5.5.1.

•

Explicit domain parameter validation as specified in Section 5.5.2, item 2.

•

Key pair generation as specified in Section 5.6.1; documentation shall include how
assurance of domain parameter validity is expected to be achieved by the key pairowner.

•

Explicit public-key validation as specified in Sections 5.6.2.3.1 and 5.6.2.3.2 for FFC
schemes or as specified in Sections 5.6.2.3.3 or 5.6.2.3.4 for ECC schemes.

•

A key-agreement scheme from Section 6, together with an approved key-derivation
method from SP 800-56C. If key confirmation is also claimed, the appropriate keyconfirmation technique from Section 5.9 shall be used. Documentation shall include
how assurance of private-key possession and assurance of domain-parameter andpublic-key validity are expected to be achieved by both the owner and the recipient.

An implementer shall also identify the appropriate specifics of the implementation,
including:•

The security strength(s) of supported cryptographic algorithms;•

The domain parameter generation method or the selected domain parameters (seeSection 5.5.1);•

The hash function(s) used, if applicable (see Section 5.1);•

The MAC algorithm(s) used, if applicable (see Section 5.2), including- The MAC key length(s) (see Section 5.9.3), and- The MAC tag length(s) (see Section 5.9.3);•

The type of cryptography supported: FFC and/or ECC;•

The key-establishment schemes supported (see Section 6);•

The key-derivation method(s), including the format of FixedInfo (see Section 5.8 andSP 800-56C);•

The type(s) of nonces supported (see Section 5.4);
123

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography•

The supported approved FFC domain parameters (if FFC schemes are supported)(see Section 5.5.1.1);•

The supported approved ECC domain parameters (if ECC schemes are supported)(see Section 5.5.1.2); and•The key-confirmation technique(s) supported, if applicable (see Section 5.9).

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

124

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

Appendix A: References
A.1 Normative References[ANS X9.42] American National Standard X9.42-2003 (R2013), Public Key Cryptography
for the Financial Services Industry: Agreement of Symmetric Keys Using
Discrete Logarithm Cryptography.
[ANS X9.63] American National Standard X9.63-2011 (R2017), Key Cryptography for the
Financial Services Industry: Public Key Cryptography for the Financial
Services Industry: Key Agreement and Key Transport Using Elliptic Curve
Cryptography.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3[FIPS 140]

Federal Information Processing Standard 140-2, Security Requirements for
Cryptographic Modules, May 25, 2001.
https://doi.org/10.6028/NIST.FIPS.140-2[FIPS 140 Annex A]
Approved Security Functions.
[FIPS 140 Annex D]
Approved Key Establishment Techniques.
[FIPS 140 IG]
National Institute of Standards and Technology, Communicationes Security
Establishment, Implementation Guidance for FIPS 140-2 and the
Cryptographic Module Validation Program, March 27, 2018,https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-ModuleValidation-Program/documents/fips140-2/FIPS1402IG.pdf.
[FIPS 180]

Federal Information Processing Standard 180-4, Secure Hash Standard,August 2015. https://doi.org/10.6028/NIST.FIPS.180-4[FIPS 186]

Federal Information Processing Standard 186-4, Digital Signature Standard,
July 2013. https://doi.org/10.6028/NIST.FIPS.186-4[FIPS 197]

Federal Information Processing Standard 197, Advanced Encryption
Standard, November 2001. https://doi.org/10.6028/NIST.FIPS.197[FIPS 198]

Federal Information Processing Standard 198-1, The Keyed-Hash Message
Authentication Code (HMAC), July 2008.
https://doi.org/10.6028/NIST.FIPS.198-1[FIPS 202]

Federal Information Processing Standard 202, SHA-3 Standard: PermutationBased Hash and Extendable-Output Functions, August 2015.
https://doi.org/10.6028/NIST.FIPS.202[RFC 3526]

More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key
Exchange (IKE), May 2003, see https://tools.ietf.org/html/rfc3526.

125

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography[RFC 4492]

Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer
Security (TLS), May 2006, see https://tools.ietf.org/html/rfc4492.

[RFC 5903]

Elliptic Curve Groups Modulo a Prime (ECP Groups) for IKE and IKEv2,
June 2010, see https://tools.ietf.org/html/rfc5903.

[RFC 7919]

Negotiated Finite Field Diffie-Hellman Ephemeral Parameters, August 2016,see https://tools.ietf.org/html/rfc7919.

[SECG]

Standards for Efficient Cryptography Group, see http://www.secg.org/.

[SEC2]
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Standards for Efficient Cryptography, SEC 2: Recommended Elliptic Curve
Domain Parameters, September 2000, see http://www.secg.org/SEC2-Ver1.0.pdf.
[SP 800-38B] Special Publication 800-38B, Recommendation for Block Cipher Modes ofOperation: The CMAC Mode for Authentication, May 2005, with updates
dated October 2016. https://doi.org/10.6028/NIST.SP.800-38B[SP 800-38C] Special Publication 800-38C, Recommendation for Block Cipher Modes ofOperation: the CCM Mode for Authentication and Confidentiality, May 2004,
with updates dated July 2007. https://doi.org/10.6028/NIST.SP.800-38C[SP 800-38F] Special Publication 800-38F, Recommendation for Block Cipher Modes ofOperation:
MethodsforKey
Wrapping,
December
2012.
https://doi.org/10.6028/NIST.SP.800-38F[SP 800-52]

Special Publication 800-52 Revision 2 (DRAFT), Guidelines for the
Selection, Configuration and Use of Transport Layer Security (TLS)
Implementations, November 15, 2017.
https://csrc.nist.gov/publications/detail/sp/800-52/rev-2/draft[SP 800-56B] Special Publication 800-56B Revision 1, Recommendation for Pair-Wise
Key-Establishment Schemes Using Integer Factorization Cryptography,
September 2014. https://doi.org/10.6028/NIST.SP.800-56Br1[SP 800-56C] Special Publication 800-56C Revision 1, Recommendation for Key
Derivation Methods in Key Establishment Schemes, April 2018.
https://doi.org/10.6028/NIST.SP.800-56Cr1[SP 800-57]

Special Publication 800-57 Part 1 Revision 4, Recommendation for Key
Management, January 2016. https://doi.org/10.6028/NIST.SP.800-57pt1r4[SP 800-89]

Special Publication (SP) 800-89, Recommendation for Obtaining
Assurances for Digital Signature Applications, November 2006.
https://doi.org/10.6028/NIST.SP.800-89[SP 800-90]

Special Publication 800-90 series:
Special Publication 800-90A Revision 1, Recommendation for Random
Number Generation Using Deterministic Random Bit Generators, June 2015.
https://doi.org/10.6028/NIST.SP.800-90Ar1

126

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

Special Publication 800-90B, Recommendation for the Entropy Sources
Used for Random Bit Generation, January 2018.
https://doi.org/10.6028/NIST.SP.800-90B
Special Publication 800-90C (DRAFT), Recommendation for Random Bit
Generator (RBG) Constructions, April 2016.
https://csrc.nist.gov/publications/detail/sp/800-90c/draft[SP 800-108] Special Publication 800-108, Recommendation for Key Derivation Using
Pseudorandom Functions, October 2009.
https://doi.org/10.6028/NIST.SP.800-108
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3[SP 800-131A] Special Publication 800-131A Revision 1, Transitions: Recommendation
for Transitioning the Use of Cryptographic Algorithms and Key Lengths,
November 2015. https://doi.org/10.6028/NIST.SP.800-131Ar1[SP 800-133] Special Publication 800-133, Recommendation for Cryptogrsphic Key
Generation, December 2012. https://doi.org/10.6028/NIST.SP.800-133[SP 800-135] Special Publication 800-135 Revision 1, Recommendation for Existing
Application-Specific Key Derivation Functions, December 2011.
https://doi.org/10.6028/NIST.SP.800-135r1[SP 800-185] Special Publication 800-185, SHA-3 Derived Functions: cSHAKE, KMAC,
TupleHash, and ParallelHash, December 2016.
https://doi.org/10.6028/NIST.SP.800-185[SP 800-186] Special Publication 800-186 (DRAFT), Recommendations for Discrete
Logarithm-Based Cryptography Elliptic Curve Domain Parameters, [future
release].
A.2 Informative References[BM 1998]

S. Blake-Wilson, A. Menezes, Unknown Key-Share Attacks on the Stationto-Station (STS) Protocol, Technical Report CORR 98-42, University ofWaterloo, 1998. Available at: http://cacr.math.uwaterloo.ca.

[CMU 2009] S. Chatterjee, A. Menezes, and B. Ustaoglu, Reusing Static Keys in Key
Agreement Protocols, INDOCRYPT 2009, LNCS Vol. 5922, pp. 39–56,
Springer-Verlag,
2009.
Availableat:
http://www.cacr.math.uwaterloo.ca/techreports/2009/cacr2009-36.pdf .
[CBH 2005]

K. R. Choo, C. Boyd, and Y. Hitchcock, On Session Key Construction in
Provably-Secure Key Establishment Protocols, LNCS, Vol. 3715, pp. 116131, Springer-Verlag, 2005. Extended version available at:
http://eprint.iacr.org/2005/206.pdf.

[ISO/IEC 8825-1]
Information technology -- ASN.1 encoding rules: Specification of Basic
Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER), 2008.
127

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography[Menezes 2007] A. Menezes, Another look at HMQV. Journal of Mathematical Cryptology,
Vol.1(1), pp. 47-64, 2007
[RBB 2001] P. Rogaway, M. Bellare, D. Boneh, Evaluation of Security Level of
Cryptography: ECMQVS (from SEC 1), Jan. 2001. Available at:
http://www.ipa.go.jp/security/enc/CRYPTREC/fy15/doc/1069_ksecmqv.pdf.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

128

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

Appendix B: Rationale for Including Identifiers and other Contextspecific Information in the KDM Input (Informative)
It is strongly recommended that identifiers for both parties to a key-agreement transaction be
included among the data input to the key-derivation method – as a simple and efficient meansof binding those identifiers to the derived keying material (see Sections 5.8).

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

The inclusion of sufficiently-specific identifiers for party U and party V provides assurance
that the keying material derived by those parties will be different from the keying material
that is derived by other parties (or by the same parties acting in opposite roles). As a result,
key-agreement schemes gain resilience against unknown-key-share attacks and/or otherexploitation techniques that depend on some type of confusion over the role played by eachparty (e.g., party U versus party V). See, for example, references [CBH 2005], [Menezes
2007], [RBB 2001], [BM 1998], and [CMU 2009], which all recommend the inclusion ofidentifiers in the key-derivation method as a means of eliminating certain vulnerabilities.
In addition to identifiers, the inclusion of other context-specific information in the keyderivation input data can be used to draw finer distinctions between key-agreementtransactions, providing assurance that parties will not derive the same keying material unlessthey agree on all of the included information. This can protect against attacks that rely on
confusion concerning the context in which key-establishment takes place and/or how thederived keying material is to be used, see [CMU 2009]. Examples of additional contextspecific information include (but are not limited to) the protocol employing the keyderivation method, protocol-defined session numbers, the key-agreement scheme that was
employed to produce the shared secret Z, any ephemeral public keys and/or nonces
exchanged during the key-agreement transaction, the bit length of the derived keying
material, and its intended use (see Section 5.8.2).
Protocols employing an approved key-agreement scheme may employ alternative methods
to bind participant identifiers (and/or other context-specific data) to the derived keying
material or otherwise provide assurance that the participants in a key-agreement transaction
share the same view of the context in which the keying material was established (including
their respective roles and identifiers). However, this Recommendation makes no statement
as to the adequacy of these other methods.

129

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

Appendix C: Data Conversions (Normative)
C.1

Integer-to-Byte String Conversion

Input:

A non-negative integer C and the intended length n of the byte string
satisfying
28n > C.
When called from an FFC Scheme, n = t / 8 bytes, where t = log2 p and pis the large prime field order.
A byte string S of length n bytes.

Output:This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

1. Jn+1 = C.
2. For i = n to 1 by -1
2.1

Ji = (Ji+1)/256.

2.2

Ai = Ji+1 − (Ji • 256).

2.3

Si = (ai1, ai2, ai3, ai4, ai5, ai6, ai7, ai8),
The 8-bit binary representation of the non-negative integer
Ai = ai1 27+ai2 26+ai3 25+ai4 24+ai5 23+ai6 22+ai7 2+ai8.

3. Let S1, S2, …, Sn be the bytes of S from leftmost to rightmost.
4. Output S.
C.2

Field-Element-to-Byte String Conversion

Input:

An element  in the field Fq.

Output:A byte string S of length n = t / 8 bytes, where t = log2 q.

1. If q is an odd prime, then  must be an integer in the interval [0, q − 1];  shall be
converted to a byte string of length n bytes using the technique specified in Appendix
C.1 above.
2. If q = 2m, then it is assumed that  is (already) represented as a bit string of length m,with each bit indicating the coefficient (0 or 1) of a specific element of a particularbasis for GF(2m) viewed as a vector space over GF(2).
Let s1, s2, …, sm be the bits of  from leftmost to rightmost. Let S1, S2, …, Sn be thebytes of S from leftmost to rightmost.
The rightmost bit sm shall become the rightmost bit of the last byte Sn, and so on
through the leftmost bit s1, which shall become the (8n − m + 1)th bit of the first byte
S1. The leftmost (8n − m) bits of the first byte S1 shall be zero.

130

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

C.3

Field-Element-to-Integer Conversion

Input:

An element  in the field Fq.

Output:An integer x.

1. If q is an odd prime, then x =  (no conversion is required).
2. If q = 2m, then  must be a bit string of length m bits. Let s1, s2, …, sm be the bits of from leftmost to rightmost.  shall be converted to an integer x satisfying:x=This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

C.4

2 − s(m i)

for i = 1 to m.

iConversion of a Bit String to an Integer

An n-long sequence of bits { x1, , xn } is converted to an integer by the rule
{ x1,  , xn } → (x1  2

n–1

n–2

) + (x2  2) +  + (n1  2) + xn .

Note that the first bit of a sequence corresponds to the most significant bit of thecorresponding integer, and the last bit corresponds to the least significant bit.
Input:
1. b1, b2,  , bn

The bit string to be converted.

Output:
1. C

The requested integer representation of the bit string.

Process:
1. Let (b1, b2,  , bn) be the bits of b from leftmost to rightmost.
2. 𝐶 = ∑𝑛𝑖=1 2(𝑛−𝑖) 𝑏𝑖 .
3. Return C.
The binary length of an integer C is defined as the smallest integer n satisfying C < 2n.

131

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

Appendix D: Approved ECC Curves and FFC Safe-prime Groups
This appendix contains lists of approved elliptic curves and safe-prime groups for key
establishment.
Warning: Additions to these lists may appear in the FIPS 140 Implementation Guidance
document, Section D.13 (IG D.13) before the next revision of this document (i.e., SP
8900-56A).
Note: entries in the same row refer to the same elliptic curve under different names. Absenceof equivalent entries is indicated by “-”.
Table 24: Appoved elliptic curves for ECC key-agreement.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Referencedin:Specified in:

FIPS 186-4
SP 800-56A
SP 800-18629
P-224
P-256
P-384
P-521
K-233
K-283
K-409
K-571
B-233
B-283
B-409
B-571

TLS (RFC 4492) IPsec w/ IKE v2(SP 800-52)(RFC 5903)
SEC 2
secp224r1
secp256r1
secp384r1
secp521r1
sect233k1
sect283k1
sect409k1
sect571k1
sect233r1
sect283r1
sect409r1
sect571r1

RFC 5903
secp256r1
secp384r1
secp521r1-

Targeted
SecurityStrengthsthat can be
Supporteds = 112112  s  128
112  s  192
112  s  256
112  s  128
112  s  128
112  s  192
112  s  256
112  s 128
112  s  128
112  s  192
112  s  256

Finite Field Cryptography Groups for Key Establishment: The following safe-primegroups are defined in RFC 3526 and RFC 7919 for use with key-agreement schemes that
employ either the FFC DH or FFC MQV primitives.
The domain parameters for these groups have the form ( p, q = (p − 1)/2, g = 2 ); the explicit
values for p are provided in the RFCs.

29

Specified in FIPS 186-4 until SP 800-186 is available.

132

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

Table 25: Approved IKE groups for FFC key agreement.
Targeted Security
Strengths that can be
Supporteds = 112112  s  128
112  s  152*
112  s  176*
112  s  200*

IKE v2(RFC 3526)
MODP-2048 (ID=14)
MODP-3072 (ID=15)
MODP-4096 (ID=16)
MODP-6144 (ID=17)
MODP-8192 (ID=18)
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

Table 26: Approved TLS groups for FFC key agreement.
Targeted Security
Strengths that can be
Supporteds = 112112  s  128
112  s  152*
112  s  176*
112  s  200*

TLS (RFC 7919)
ffdhe2048 (ID = 256)
ffdhe3072 (ID = 257)
ffdhe4096 (ID = 258)
ffdhe6144 (ID = 259)
ffdhe8192 (ID = 260)

* The maximum security strength estimates were calculated using formula in Section 7.5of the FIPS 140 IG and rounded to the nearest multiple of eight bits.

133

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

Appendix E: Revisions (Informative)

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

The original version of this document was published in March, 2006. In March, 2007, thefollowing revision was made to allow the dual use of keys during certificate requests:
In Section 5.6.4.2, the second item was originally as follows:“A static key pair may be used in more than one key-establishment scheme. However,
one static public/private key pair shall not be used for different purposes (forexample, a digital signature key pair is not to be used for key establishment or viceversa).”The item was changed to the following, where the changed text is indicated in italics:“A static key pair may be used in more than one key-establishment scheme. However,
one static public/private key pair shall not be used for different purposes (forexample, a digital signature key pair is not to be used for key establishment or viceversa) with the following possible exception: when requesting the (initial) certificate
for a public static key-establishment key, the key establishment private key associatedwith the public key may be used to sign the certificate request. See SP 800-57, Part 1
on Key Usage for further information.”

In May 2013, the following revisions were made;•

Abstract – The March 2007 version cites ANS X9.42 and X9.63; this version directly
provides information on the key establishment schemes (DH, MQV) and theunderlying mathematics structure (discrete logs on finite field, elliptic curve).

•

Section 3.1 – Added definitions of assumption, binding, bit string, byte, byte string,
destroy, key-establishment pair, key-wrapping key, trusted association; removed
definitions on assurance of identifier, initiator, responder, (instead initiator andresponder, all the schemes are defined in terms of party U and party V, see revisionin Section 4), extended keying material to derived keying material (derived from theshared secret) and transported keying material (generated by the sender in a keytransport scheme.)•

Section 3.2 – The notations, C(ie), C(ie, js), MAC(MacKey, MacData), MacTag,
T_bitlen(X), were introduced; the notation |x | is removed.

•

Section 3.2 – Notations Z, Ze, Zs are used for both FFC and ECC and therefore moved
up as general notations.

•

Section 3.2 – The terms GF(p), GF(p)* were introduced for FFC.

•

Section 4 – Used party U and party V to name the parties, rather than user the initiatorand responder as the parties. Discussions about identifiers vs. identity and binding
have been moved to Section 4.1.

•

Section 4.1 – Added discussions on the concept of a trusted association;•

Section 5 – Table 1 in March 2007 version has been removed; the information is now
provided in Tables 6 and 7 in Section 5.8.1, and Tables 8 and 9 in Section 5.9.3.
134

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3•

Section 5.2 – Provided more details on MAC inputs (MacKey and MacData). Added
text that MACs can be used for key derivation, as well as key confirmation. Added
SP 800-38B (CMAC) as an approved MAC. Refers to the new Tables 6 and 7.

•

Section 5.2.1 - MacLen now is a parameter, rather than an input variable. Refers to
new Tables 8 and 9, instead of old Tables 1 and 2. Discusses the truncation of the
MAC output.

•

Section 5.4 – More discussion has been added about the use of nonces, including new
requirements and recommendations.

•

Section 5.5.1.1 – Added the requirement that the leftmost bit of p and q be a 1. Table
1 has been shortened to address just the values of p and q; information about the hashfunction is now provided in Tables 6 and 7 of Section 5.8.1, and in Tables 8 and 9 ofSection 5.9.3.

•

Section 5.5.1.2 – More information is provided about elliptic curves. More details
are provided on parameter values. Table 2 has been shorted to just address n and h;
information about the hash function is now provided in Tables 6 and 7 of Section
5.8.1, and in Tables 8 and 9 of Section 5.9.3.

•

Section 5.5.2 – A note about parameters generated by using SHA-1has been removed.
The validation methods are referred to other documents (FIPS 186 and ANS X9.62).
It is not a right place for such statement.

•

Section 5.6 has been reorganized to make it clearer to understand key generation andobtaining the required assurances.

•

Section 5.6.1.1 – FFC key-pair generation has been revised to require a randomly
selected integer in the interval [2, q−2], rather than requiring a private key for FFC
key pair generation to be unpredictable and generated by an approved RNG.
Generation in accordance with FIPS 186-3 (as referenced therein) fulfills theserequirements.

•

Section 5.6.1.2 – ECC key-pair generation has been revised to require a randomly
selected integer in the interval [2, n−2], rather than requiring a private key for ECC
key pair generation to be unpredictable and generated by an approved RNG.
Generation in accordance with FIPS 186-3 (as referenced therein) fulfills theserequirements.

•

New Section 5.6.2 – Discusses assurances and why they are required. Added Tables
3, 4, and 5 which summarize types of assurance.

•

New Section 5.6.2.1 – Discusses the assurances required by a key-pair owner about
its own key pair, including owner assurance of correct generation, static andephemeral public-key validity, pair-wise consistency and private-key possession.

•

New Section 5.6.2.2 – Discusses the assurances required by a public-key recipient,including static and ephemeral public-key validity, and static and ephemeral privatekey possession.
135

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3•

New Sections 5.6.3.2 and 5.6.3.3 – Different requirements are included for static andephemeral key pairs. Included a case that an agent may act on behalf of a system
user.

•

Section 5.7 – Added requirements to destroy all values if there is an error and todestroy intermediate calculations have been added for each FFC and ECC primitive.
Conversion calls have been added to convert to a string. Note that this removed suchstatements for the action steps for each scheme in Section 6.

•

Section 5.8 – Key derivation has been divided into one-step key-derivation methods(Section 5.8.1), an extract-then-expand key-derivation procedure (Section 5.8.2) andapplication-specific key-derivation methods (Section 5.8.3).

•

Section 5.8.1 – Instead of using a hash function, the one-step method is now definedwith a function H, which can be a hash function or an HMAC with an approved hashfunction. Added tables defining minimum length for the hash functions with regard
to each parameter set; and added more complete discussions about OtherInfo,
including the concatenation and ASN.1 formats included in the previous version.
HMAC with an approved hash function is now approved for key derivation, in
addition to the hash function specified in the previous version.

•

Section 5.8.1 – Split Table 1 (for FFC) to Table 1 (Section 5.5.1.1), Table 6 (Section
5.8.1) and Table 8 (Section 5.9.3), where Table 1 is for FFC parameter-size sets,
Table 6 is for the function H used for key derivation and Table 8 is about the MAC
key length and MAC tag length. In the new tables, added row on “Maximum security
strength supported”.

•

Section 5.8.1 – In Table 6, changed the minimum output length for function H from
128 to 112 for FFC parameter set.

•

Section 5.8.1 - Split Table 2 (for ECC) to Table 2 (Section 5.5.1.2), Table 7 (Section
5.8.1) and Table 9 (Section 5.9.3), where Table 2 is for ECC parameter-size sets,
Table 7 is for the function H used for key derivation, and Table 9 is about the MAC
key length and MAC tag length. In the new tables, added row on “Maximum security
strength supported”.

•

Section 5.8.2 – Added reference to an approved two-step method – an extractionthen-expansion method – that is specified in SP 800-56C.

•

Section 5.8.3 – Added reference to the application-specific key-derivation methods
provided in SP 800-135.

•

Moved general introduction of key confirmation to Section 5.9 – Incorporates thematerial from Section 8 (with additional introductory material).

•

New Section 5.9.1.1 – Emphasizes more clearly that a nonce is required if there is noephemeral key; added guidance on what to do if key confirmation fails.

•

New Section 5.9.2 – Emphasizes that if no ephemeral key is used, then a nonce isrequired.
136

NIST SP 800-56A Rev. 3

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3•

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography•

New Section 5.9.3 – Discussions about the security strength of the MacTag areprovided, along with tables on the minimum MacKey length and MacLen values.

•

New Section 5.9.3 – Table 8, changed the minimum MacLen, that is, MacTag length
to 64 bits for all the parameter sets of FFC.

•New Section 5.9.3 – Table 9, changed the minimum MacLen, that is, MacTag length
to 64 bits for all the parameter sets of ECC.

•

Section 6 – The notation C(ie) replaces C(i), and C(ie, js) replaces C(i, j). If party U
does not contribute a static key, then the requirement for a non-null identifier is now
transaction dependent, rather than required. Rationale for choosing the C(ie, js)
schemes has been moved to a new Section 8, instead of after each class of schemes.
Assumptions are specified for each type of scheme, rather than prerequisites.

•

Section 6.1.1 (and similarly for Sections 6.2.1, 6.2.2 and 6.3) –Added a new
assumption that if an identifier is used as a label, then the identifier must have atrusted association to that party’s static key. The discussion on the need for a trusted
association has been added.

•

Section 6.1.1.1 (dhHybrid1) – More guidance is provided about error handling.
Specifically allows the reuse of an ephemeral key pair in a broadcast scenario. Thisis also provided in Sections 6.1.1.2, 6.1.1.3 and 6.1.1.4.

•

New Section 6.1.1.5 (and similarly in new Sections 6.1.2.3, 6.2.1.5, 6.2.2.3 and 6.3.3)– Key confirmation is incorporated to each applied subcategory of schemes. This
material was previously provided in Section 8.4 of the previous version.

•

Section 6.2.1 (C(1e,2s) schemes) – Added additional assumptions which were
included in the previous prerequisites. This includes obtaining assurance of static
public key validity and private keys possession of the key-pair owner.

•

Section 7 – Has been revised to specify DLC-based key-agreement and key transport
in the same key-establishment transaction, with party U acting as the key-transport
sender. In addition, optional key confirmation from party V to party U following the
key-transport process has been specified.

•

Section 8 – The rationale for choosing each scheme type has been moved from
Section 6 of the previous version. A new section on the rationale associated with key
transport has been included.

•

All figures are replaced to reflect the content, text, and terminology changes.

•

Old Appendix A, Summary of Differences between this Recommendation and ANS
X9 Standards, was removed. Note that X9.42 was withdrawn, while X9.63 has
modified to be consistent with this Recommendation.
Appendix B – The requirement of including identifiers as part of the OtherInfo isreplaced with text that. it is strongly recommended that identifiers for both parties to a
key-agreement transaction be included among the data input to a key-derivation
method. A paragraph has been added stating that there may be other ways to bind
137

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

identifiers to derived keying material, but the recommendation makes no statement on
the adequacy of this.
•The new Appendix A includes all the informative references, which was in Appendix
D in March 2007 version.

•

The old Appendix E becomes Appendix D and the changes on March 2007 version
are added as listed here.

In 2018, the following revisions were made:1. Inserted hyperlinks for sections, references and definitions.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

2. Text about key transport and broadcasting has been removed, except for a short
discussion of key transport in Section 4.3.
3. Tables 1, 2 6 and 7: Changed column 1, row 1 to "Targeted security strength" insteadof "Maximum security strength supported"
4. Section 3.1: Added definitions for critical security parameter, cryptographic moduleand MacOutputBits. Updated the definition of destroy, integrity, key-derivation
procedure, key-establishment transaction, key-wrapping algorithm, key-wrapping
key, MacTagBits, message authentication code, shared secret, symmetric key
algorithm, store-and-forward and targeted security strength. Modified the definition
for fresh, and key confirmation, Mac tag.
5. Section 3.2: Inserted CSP, len(x), MacOutputBits and RBG. Removed H and HMAChash. Modified MacTag. MacTagLen was changed to MacTagBits. (Uses of
MacOutputLen in the document were changed to MacOutputBits).
6. Section 4: Inserted additional paragraphs the security of a key-establishment schemeand explicit instructions for the destruction of certain potentially sensitive values.
Inserted a requirement that values explicitly required to be destroyed when leaving aroutine (i.e., potentially sensitive locally stored data) shall not be used or reused forany additional purpose.
7. Section 4.1, paragraph 2, mentioned that domain parameters may be from anapproved list. Paragraph 3: Explained what is meant by transporting in a "protectedmanner."
8. Section 5.1: Inserted a reference to FIPS 202.
9. Section 5.2: Paragraph 3 − added KMAC to the list of approved MACs. Paragraph 5− referred to SP 800-56C for the case where a MAC is used for key derivation.
10. Section 5.2.1, item 2: Changed “is required to” to “shall”. MacLen has been renamed
to be MacTagBits for clarity.
11. Section 5.5: Revised wording.
12. Section 5.5.1.1: Certain FFC groups defined in other standards are now approved foruse, which are encouraged for use. The old parameter-size sets in Table 1 are now
addressed as FIPS 186-type sets and recommended for use only in legacy
applications. Parameter-size set FA was removed. Table 1 has been shortened to138

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

address just the values of p and q; information about the hash function is now
provided in Section 5.8.1 and Section 5.9.3. For the FIPS 186-type parameter-size
sets, a requirement was added that the leftmost bit of p and q be a 1.
13. Section 5.5.1.2: Removed the table of parameter-size sets. Elliptic curves will be
specified in SP 800-186 (when available; will continue to be available in FIPS 186
until then). References to ASC X9.62 have been removed.
14. Section 5.5.2: Inserted an assurance method that allows approved safe-prime groupsof domain parameters.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

15. Section 5.6.1.1: Added discussions about the generation of key pairs for both theapproved safe-prime groups and the FIPS 186-type parameter-size sets. The FFC keypair generation routines from FIPS 186-4 were added (with some modifications). A
reference to SP 800-133 is included for generating the keys.
16. Section 5.6.1.2: The ECC key-pair generation routines from FIPS 186-4 were added(with some modifications).
17. Section 5.6.2.1.2: Revised to accommodate the safe-prime groups.
18. Sections 5.6.2.1.3, 5.6.2.1.4 and 5.6.2.1.5: Revised for further clarity.
19. Section 5.6.2.1.4: The alternative test in method b was removed.
20. Section 5.6.2.2.2: Revised to accommodate the safe-prime groups.
21. Section 5.6.2.3: Introductory text added.
22. Section 5.6.2.3.1: Now specified as a method for FFC full public-key validation. The
comment on process step 1 has been revised for clarity.
23. Section 5.6.2.3.2: New section added on FFC partial public-key validation.
24. Sections 5.6.2.3.1, 5.6.2.3.2 and 5.6.2.3.3: Added text to say that when an error isfound, the routine should be exited immediately without further processing.
25. Section 5.6.2.2.2: Changed “The recipient of another party’s ephemeral public key isrequired to obtain assurance…” to “The recipient of another party’s ephemeral public
key shall obtain assurance…”.
26. Section 5.6.2.2.4, items 2 and 3: Added further clarifications.
27. Section 5.6.3.2: Public keys generated using the approved safe primes shall not be
used for digital signatures.
28. Section 5.6.3.3: Added further clarification to item 1 to state that the private key
needs to be protected until destroyed and is not to be backed up, archived or escrowed.
29. Section 5.7.1.1: Clarified error handling in step 2, and added checks for z = p − 1 andz = 0.
30. Section 5.7.1.2: Clarified error handling in step 2.
31. Section 5.7.2.1: Clarified error handling in step 6.
32. Section 5.7.2.3: Clarified error handling in step 3.
139

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

33. Section 5.8: Inserted a requirement that the shared secret shall be used only by anapproved key-derivation method and shall not for any other purpose. Inserted an
explicit statement that SP800-56A approves the key-derivation methods only for thederivation of keys from a shared secret.

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

34. Moved all key-derivation methods to SP 800-56C. Inserted a new section (Section
5.8.1) to describe how to call a key-derivation method and reorganized Section 5.8.
35. To avoid confusion between the use of OtherInput and OtherInfo in the previous
version of this document, OtherInfo was changed to FixedInfo; this information isused as fixed input to the key-derivation method. keydatalen was changed to L for(eventual) consistency between SP 800-56A/B/C and SP 800-108.
36. In the new Section 5.8.2.1, inserted text in SuppPubInfo and SuppPrivInfo that states
that, while an implementation may be capable of including these subfields, thesubfields may be null for a given transaction.
37. Section 5.8.2.2 clarifies the interaction with the two-step key-derivation procedure in
SP 800-56C.
38. Section 5.9.1: Changed “Each party is required to have an identifier…” to “Eachparty shall have an identifier…”. Also, inserted text that discusses the EphemPubKeyi
string and conversions to FFC and ECC schemes.
39. Section 5.9.1.1: Appended to Section 5.9.1, since there was no Section 5.9.1.2. Text
was added to clarify the use of an ephemeral public key in the MacData.
40. Section 5.9.1.1 (step 1) and 5.9.2: The requirement for a "random nonce" waschanged to a requirement for a "nonce" to be consistent with Section 5.4 and the key
confirmation subsections of Section 6.
41. Section 5.9.3: Modified text to approve the use of KMAC as a MAC algorithm.
Removed the domain parameter-size sets, referring to Section 5.5.1 for the domain
parameter information. Provided text specifying that the MacKey length needs to beat least the supported security strength of the domain parameters and the Mac tag
length needs to be at least 64 bits. Also, added text and a table that identifies theapproved MAC algorithms, values for MacOutputBits and the security strengths
that they can support.
42. Section 6.1.1: Modified the first assumption to refer to Section 5.5.1 for the domain
parameter information. Now refer to Section 5.9.3 for the minimum MacKey and Mac
tag lengths.
43. Section 6.1.1.1-6.1.1.4: Clarified error handling.
44. Section 6.1.2: Modified the first assumption to refer to Section 5.5.1 for the domain
parameter information. Now refer to Section 5.9.3 for the minimum MacKey and Mac
tag lengths.
45. Section 6.1.2.1-6.1.2.2: Clarified error handling.
46. Section 6.2.1: Modified the first assumption to refer to Section 5.5.1 for the domain
parameter information. Now refer to Section 5.9.3 for the minimum MacKey and Mac
tag lengths.
140

NIST SP 800-56A Rev. 3

Recommendation for Pair-Wise Key Establishment
Using Discrete Logarithm Cryptography

47. Section 6.2.1.1-6.2.1.4: Clarified error handling.
48. Section 6.2.2: Modified the first assumption to refer to Section 5.5.1 for the domain
parameter information. Now refer to Section 5.9.3 for the minimum MacKey and Mac
tag lengths.
49. Section 6.2.2.1-6.2.2.2: Clarified error handling.
50. Section 6.3: Modified the first assumption to refer to Section 5.5.1 for the domain
parameter information. Now refer to Section 5.9.3 for the minimum MacKey and Mac
tag lengths.
51. Section 6.31-6.3.2: Clarified error handling.
This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-56Ar3

52. Old Section 7: Removed.
53. Section 7.6 (old Section 8.6): Changed to be a summary of the properties discussed
in Sections 7.1 - 7.5 for the schemes in this Recommendation.
54. Section 9 (old Section 10): Modified to refer to SP 800-56C for key-derivation
methods.
55. Appendix A: Updated the FIPS and SP references.
56. Appendix B: Changed the title.
57. Appendix C.1: Changed the routine to specify the technique used in SP 800-56B;
the same results should be obtained.
58. Appendix C.4: Added a bit string to integer conversion routine.
59. Appendix D: Inserted an appendix listing the approved safe-prime groups and a tableproviding various names for the NIST-recommended elliptic curves currently
specified in FIPS 186-4. The curves will be moved to SP 800-186. The supported
security strengths for the curves and the safe-prime groups is included in the tables.

141