Académique Documents
Professionnel Documents
Culture Documents
800-56Br1
Elaine Barker
Lily Chen
Dustin Moody
http://dx.doi.org/10.6028/NIST.SP.800-56Br1
C O M P U T E R S E C U R I T Y
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.SP.800-56Br1
Elaine Barker
Lily Chen
Dustin Moody
Computer Security Division
Information Technology Laboratory
September 2014
Authority
This publication has been developed by NIST in accordance with its statutory responsibilities under the
Federal Information Security Management Act of 2002 (FISMA), 44 U.S.C. 3541 et seq., Public Law
107-347. 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 is consistent with the requirements of the Office of
Management and Budget (OMB) Circular A-130, Section 8b(3), Securing Agency Information Systems, as
analyzed in Circular A-130, Appendix IV: Analysis of Key Sections. Supplemental information is
provided in Circular A-130, Appendix III, Security of Federal Automated Information Resources.
Nothing in this publication should be taken to contradict the standards and guidelines made mandatory
and binding on Federal agencies by the Secretary of Commerce under statutory authority. Nor should
these guidelines 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
nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States.
Attribution would, however, be appreciated by NIST.
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 accordance with 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 each publication 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. All NIST Computer Security Division publications, other than the ones
noted above, are available at http://csrc.nist.gov/publications.
ii
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.SP.800-56Br1
Abstract
This Recommendation specifies key-establishment schemes using integer factorization cryptography,
based on ANS X9.44, Key-establishment using Integer Factorization Cryptography [ANS X9.44], which
was developed by the Accredited Standards Committee (ASC) X9, Inc.
Keywords
assurances; integer factorization cryptography; key agreement; key confirmation; key derivation;
key-establishment; key management; key recovery; key-transport.
Acknowledgements
This publication was developed in collaboration with the National Security Agency (NSA). The
Federal Information Security Management Act of 2002 mandates that NIST consult with the
NSA on standards and guidelines for securing information systems. In particular, NIST wishes
to acknowledge the substantial contributions made by Rich Davis of the NSA, who served on
this publication's development team. He helped to develop the technical content of these
guidelines and provided editorial review.
NIST also thanks the many contributions by the public and private sectors whose thoughtful and
constructive comments improved the quality and usefulness of this publication. The authors also
acknowledge the contributions by Andrew Regenscheid and Miles Smid made to the previous
version of this Recommendation.
Conformance Testing
Conformance testing for implementations of this Recommendation will be conducted within the
framework 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.
iii
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.SP.800-56Br1
Table of Contents
1 Introduction ............................................................................................................................. 1
2 Scope and Purpose .................................................................................................................. 1
3 Definitions, Symbols and Abbreviations ............................................................................... 1
3.1 Definitions........................................................................................................................ 1
3.2 Symbols and Abbreviations ............................................................................................. 8
4 Key-Establishment Schemes Overview ............................................................................... 14
4.1 Key-Establishment Preparations .................................................................................... 15
4.2 Key-Agreement Process................................................................................................. 17
4.3 Key-Transport Process ................................................................................................... 18
5 Cryptographic Elements ...................................................................................................... 20
5.1 Cryptographic Hash Functions ...................................................................................... 20
5.2 Message Authentication Code (MAC) Algorithms ....................................................... 20
5.2.1 MacTag Computation for Key Confirmation .................................................... 20
5.2.2 MacTag Verification for Key Confirmation ...................................................... 21
5.3 Random Bit Generators.................................................................................................. 21
5.4 Nonces............................................................................................................................ 21
5.5 Key-Derivation Methods ............................................................................................... 22
5.5.1 The Single-step Key-Derivation Function ......................................................... 23
5.5.1.1 The Single-step KDF Specification .................................................... 23
5.5.1.2 OtherInfo ............................................................................................. 25
5.5.2 The Extraction-then-Expansion Key-Derivation Procedure .............................. 28
5.5.3 Application-Specific Key-Derivation Methods ................................................. 28
5.6 Key Confirmation .......................................................................................................... 28
5.6.1 Unilateral Key Confirmation for Key-Establishment Schemes ......................... 29
5.6.1.1 Adding Unilateral Key Confirmation to a Key-Establishment Scheme
............................................................................................................. 29
iv
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.SP.800-56Br1
v
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.SP.800-56Br1
vi
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.SP.800-56Br1
vii
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.SP.800-56Br1
viii
This publication is available free of charge from http://dx.doi.org/10.6028/NIST.SP.800-56Br1
Figures
Figure 1: Owner Key-establishment Preparations .........................................................................16
Figure 2: Key-Agreement Process .................................................................................................17
Figure 3: Key-transport Process.....................................................................................................19
Figure 4: RSA-OAEP Encryption Operation .................................................................................65
Figure 5: RSA-OAEP Decryption Operation ................................................................................68
Figure 6: RSA-KEM-KWS Encryption Operation ........................................................................76
Figure 7: RSA-KEM-KWS Decryption Operation ........................................................................79
Figure 8: KAS1-basic Scheme .......................................................................................................83
Figure 9: KAS1-Party_V-confirmation Scheme (from Party V to Party U) .................................84
Figure 10: KAS2-basic Scheme .....................................................................................................88
Figure 11: KAS2-Party_V-confirmation Scheme (from Party V to Party U) ...............................90
Figure 12: KAS2-Party_U-confirmation Scheme (from Party U to Party V) ...............................91
Figure 13: KAS2-bilateral-confirmation Scheme ..........................................................................92
Figure 14: KTS-OAEP-basic Scheme ...........................................................................................97
Figure 15: KTS-OAEP-Party_V-confirmation Scheme ................................................................98
Figure 16: KTS-KEM-KWS-basic Scheme .................................................................................102
ix
1 Introduction
Many U.S. Government Information Technology (IT) systems need to employ strong
cryptographic schemes to protect the integrity and confidentiality of the data that they process.
Algorithms such as the Advanced Encryption Standard (AES), as defined in Federal Information
Processing Standard (FIPS) 197 [FIPS 197]; Triple DES, as specified in NIST Special
Publication (SP) 800-67 [SP 800-67]; and HMAC, as defined in FIPS 198 [FIPS 198] make
attractive choices for the provision of these services. These algorithms have been standardized to
facilitate interoperability between systems. However, the use of these algorithms requires the
establishment of secret keying material that is shared in advance. Trusted couriers may manually
distribute this secret keying material, but as the number of entities using a system grows, the
work involved in the distribution of the secret keying material grows rapidly. Therefore, it is
essential to support the cryptographic algorithms used in modern U.S. Government applications
with automated key-establishment schemes.
This Recommendation provides the specifications of key-establishment schemes that are
appropriate for use by the U.S. Federal Government, based on a standard developed by the
Accredited Standards Committee (ASC) X9, Inc.: ANS X9.44, Key Establishment using Integer
Factorization Cryptography [ANS X9.44]. A key-establishment scheme can be characterized as
either a key-agreement scheme or a key-transport scheme. This Recommendation provides
asymmetric-based key-agreement and key-transport schemes that are based on the Rivest Shamir
Adleman (RSA) algorithm. When there are differences between this Recommendation and the
referenced ANS X9.44 [ANS X9.44] standard, this key-establishment schemes Recommendation
shall have precedence for U.S. Government applications.
Additional input Information known by two parties that is cryptographically bound to the
keying material being protected using the encryption operation.
1
Approved Federal Information Processing Standards (FIPS)-approved or NIST-
recommended. An algorithm or technique that meets at least one of the
following: 1) is specified in a FIPS or NIST Recommendation, 2) is
adopted in a FIPS or NIST Recommendation or 3) is specified in a list
of NIST-approved security functions (e.g., specified as approved in
the annexes of FIPS 140 [FIPS 140]).
Assumption Used to indicate the conditions that are required to be true when an
approved key-establishment scheme is executed in accordance with
this Recommendation.
Assurance of validity Confidence that either a key or a key pair is arithmetically correct.
Certification The entity in a Public Key Infrastructure (PKI) that is responsible for
Authority (CA) issuing public-key certificates and exacting compliance to a PKI policy.
Cryptographic key A parameter used with a cryptographic algorithm that determines its
(Key) operation.
Data integrity A property whereby data has not been altered in an unauthorized
manner since it was created, transmitted or stored.
In this Recommendation, the statement that a cryptographic algorithm
"provides data integrity" means that the algorithm is used to detect
unauthorized alterations.
2
Decryption The process of transforming ciphertext into plaintext using a
cryptographic algorithm and key.
Greatest common The largest positive integer that divides each of two positive integers
divisor without a remainder.
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 the following
properties:
1. One-way: It is computationally infeasible to find any input that
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.
3
Key-agreement A key-establishment event which results in secret keying material that
transaction is shared between the parties using a key-agreement scheme.
Key-confirmation The party that provides assurance to the other party (the recipient) that
provider the two parties have indeed established a shared secret or shared keying
material.
Key-derivation A function used to derive keying material from a shared secret (or a
function key) and other information.
Key-derivation A method by which keying material is derived from a shared secret and
method other information. A key-derivation method may use a key-derivation
function or a key-derivation procedure.
Key establishment The procedure that results in keying material that is shared between the
participating parties in a key-establishment transaction.
Key management The activities involved in the handling of cryptographic keys and other
related security parameters (e.g., initialization vectors (IVs) and
passwords) during the entire life cycle of the keys, including their
generation, storage, establishment, entry and output, and destruction.
Key pair A public key and its corresponding private key; a key pair is used with a
public-key algorithm.
Key transport A key-establishment procedure whereby one party (the sender) selects a
value for the secret keying material and then securely distributes that
value to another party (the receiver). Contrast with key agreement.
Key wrapping A method of protecting keying material (along with associated integrity
information) that provides both confidentiality and integrity protection
when using a symmetric-key algorithm.
4
Key-wrapping key In this Recommendation, a key-wrapping key is a symmetric key
established during a key-transport transaction and 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 non-overlapping
segments of the string with the required lengths can be used as
symmetric cryptographic keys. In this Recommendation, keying
material is derived from a shared secret established during an execution
of a key-agreement scheme, or transported by the sender in a key-
transport scheme. As used in this Recommendation, secret keying
material may include keys, secret initialization vectors, and other secret
parameters.
Least common The smallest positive integer that is divisible by two positive integers
multiple without a remainder. For example, the least common multiple of 2 and
3 is 6.
Length in bits of a The length, in bits, of the shortest bit string containing the binary
non-negative integer x representation of x. For example, the length in bits of 5 (i.e., 101) is 3.
When x = 0, its length in bits is 1.
Length in bytes of a The length, in bytes, of the shortest byte string containing the binary
non-negative integer, representation of x. For example, the length in bytes of 5 is 1. When x =
x 0, its length in bytes is 1.
MAC tag Data obtained from the output of a MAC algorithm that can be used by
an entity to verify the integrity and the origination of the information
used as input to the MAC algorithm.
Owner For a key pair, the owner is the entity that is authorized to use the
private key associated with a public key, whether that entity generated
the key pair itself or a trusted party generated the key pair for the entity.
5
Party An individual (person), organization, device, or process. Entity is a
synonym for party.
Prime number An integer that is greater than 1 and divisible only by 1 and itself.
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 special set of rules used by two or more communicating entities that
describe the message order and data structures for information
exchanged between the entities.
Provider A 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 a public
key; or (3) key confirmation. Contrast with recipient.
Public key A cryptographic key that may be made public and is used with a public-
key cryptographic algorithm. A public key is associated with a private
key.
Public-key algorithm A cryptographic algorithm that uses two related keys, a public key and a
private key. The two keys have the property that determining the private
key from the public key is computationally infeasible.
Public-key certificate A data structure that contains an entitys identifier(s), the entity's public
key and possibly other information, along with a signature on that data
set that is generated by a trusted party, i.e. a certificate authority,
thereby binding the public key to the included identifier(s).
Public-key A form of cryptography that uses two related keys, a public key and a
cryptography private key; the two keys have the property that, given the public key, it is
computationally infeasible to derive the private key.
For key establishment, public-key cryptography allows different parties
to communicate securely without having prior access to a secret key
that is shared, by using one or more pairs (public key and private key)
of cryptographic keys.
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 order to
thwart certain types of attacks.
6
Receiver The party that receives secret keying material via a key-transport
transaction. Contrast with sender.
Recipient A party that receives (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 a public
key; or (3) key confirmation. Contrast with provider.
Relatively prime Two positive integers are relatively prime if their greatest common
divisor is 1.
Secret keying As used in this Recommendation, the secret keying material that is
material (that is either (1) derived by applying the key-derivation method to the shared
shared) secret and other shared information during a key-agreement transaction,
or (2) is transported during a key-transport transaction.
Security properties The security features (e.g., entity authentication, replay protection, or
key confirmation) that a cryptographic scheme may, or may not,
provide.
Security strength A number associated with the amount of work (that is, the number of
(also, Bits of operations) that is required to break a cryptographic algorithm or
security) system.
Sender The party that sends secret keying material to the receiver using a key-
transport transaction. Contrast with receiver.
Shared secret A secret value that has been computed during a key-establishment
scheme, is known by both participants, and is used as input to a key-
derivation method to produce keying material.
7
Symmetric key A single cryptographic key that is used with a secret (symmetric) key
algorithm.
Symmetric-key A cryptographic algorithm that uses one secret key that is shared
algorithm between authorized parties.
Target security The desired security strength for a cryptographic application. The target
strength security strength is selected based upon the amount of security desired
for the information protected by the keying material established using
this Recommendation.
Trusted party A party that is trusted by an entity to faithfully perform certain services
for that entity. An entity may choose to act as 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, for example, the sender and receiver in a
scheme are considered to be the first and second parties in a key-
establishment transaction).
c Ciphertext; an integer.
8
CA Certification Authority.
dP RSA private exponent for the prime factor p in the CRT format,
i.e., d mod (p-1); an integer.
dQ RSA private exponent for the prime factor q in the CRT format,
i.e., d mod (q-1); an integer.
IDP, IDR, IDU, IDV Identifier bit strings for parties P, R, U, and V, respectively.
9
KAS Key-Agreement Scheme.
KC Key Confirmation.
KeyData Keying material other than that which is used for the MacKey
employed in key confirmation.
KTS-KEM-KWS-basic The basic form of the key-transport Scheme with the Key
Encapsulation Mechanism and Key-Wrapping Scheme.
10
kwkBits Length in bits of the key-wrapping key.
MacDataU, (or MacDataV) MacData associated with party U (or party V, respectively), and
used to generate MacTagU (or MacTagV, respectively). Each is a
byte string.
MacTag A byte string that allows an entity to verify the integrity of the
information. MacTag is the output from the MAC algorithm
(possibly after truncation). The literature sometimes refers to
MacTag as a Message Authentication Code (MAC).
MacTagV, (MacTagU) The MacTag generated by party V (or party U, respectively). Each
is a byte string.
(n, e, d, p, q, dP, dQ, qInv) RSA private key in the Chinese Remainder Theorem (CRT)
format.
11
nLen Length in bytes of the RSA modulus n.
S String of bytes.
12
V Another party in a key-establishment scheme.
(n) Lambda function of the RSA modulus n, i.e., the least positive
integer i such that 1= ai mod n for all a relatively prime to n.
When n=pq, (n) = LCM(p-1, q-1).
13
4 Key-Establishment Schemes Overview
Secret cryptographic keying material may be electronically established between parties by using
a key-establishment scheme, that is, by using either a key-agreement scheme or a key-transport
scheme. Key-establishment schemes may use either symmetric-key techniques or asymmetric-
key techniques or both. The key-establishment schemes described in this Recommendation use
asymmetric-key techniques.
In this Recommendation, the approved key-establishment schemes are described in terms of the
roles played by parties U and V. These are specific labels that are used to distinguish between
the two participants engaged in key establishment irrespective of the actual labels that may be used
by a protocol employing a particular approved key-establishment scheme.
During key agreement, the derived secret keying material is the result of contributions made by both
parties. 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 U and V to the
participants by clearly defining which participant performs the actions ascribed by this
Recommendation to party U, and which performs the actions ascribed herein to party V.
During key transport, one party selects the secret keying material to be transported. The secret
keying material is then encrypted/wrapped, and sent to the other party. The party that sends the
secret keying material is called the sender, and the other party is called the receiver. In this
Recommendation, key-wrapping is performed in the same transaction that establishes the key-
wrapping key using an approved key-transport scheme, and party U is always assigned the role
of the sender, while party V is the receiver.
The security of the Integer Factorization Cryptography (IFC) schemes in this Recommendation
relies on the intractability of factoring integers that are products of two sufficiently large, distinct
prime numbers. All IFC schemes in this Recommendation are based on RSA.
The security of an IFC scheme also depends on its implementation, and this document includes a
number of 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 particular procedure, and whose 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 the procedure. This is intended to limit
opportunities for unauthorized access to sensitive information that might compromise a key-
establishment process.
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 this Recommendation.
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 a procedure employed in a particular implementation.
Nevertheless, the destruction of any potentially sensitive locally stored data is an obligation of all
implementations.
14
Error handling can also be an issue. Section 7 cautions implementers to handle error messages in
a manner that avoids revealing even partial information about the decryption/decoding processes
that may be performed during the execution of a particular procedure.
For compliance with this Recommendation, equivalent processes may be used. Two processes
are equivalent if, whenever the same values are input to each process (either as input parameters
or as values made available during the process), each process produces the same output as the
other.
Some processes are used to provide assurance (for example, assurance of the arithmetic validity
of a public key or assurance of possession of a private key associated with a public key). The
party that provides the assurance is called the provider (of the assurance), and the other party is
called the recipient (of the assurance).
A number of steps are performed to establish secret keying material as described in Sections 4.1,
4.2, and 4.3.
15
owners possession of the private key corresponding to that public key. (Approved techniques
that can be employed by the binding authority to obtain these assurances are described in Section
6.4.2.1 [method 1], Section 6.4.2.2, Section 6.4.2.3 and Section 6.4.2.3.2.)
As an alternative to reliance upon a binding authority, trusted associations between identifiers
and public keys may be established by the direct exchange of this information between entities,
using a mutually trusted method (e.g., a trusted courier or a face-to-face exchange). In this case,
each entity receiving a public key and associated identifier(s) shall be responsible for obtaining
the same assurances that would have been obtained on the entitys behalf by a binding authority
(see the previous paragraph). Entities shall also be responsible for maintaining (by cryptographic
or other means) the trusted associations between any identifiers and public keys received through
such exchanges.
If an entity engaged in a key-establishment transaction owns a key pair that is employed during
the transaction, then the identifier used to label that party shall be one that has a trusted
association with the public key of that key pair. If an entity engaged in a key-establishment
transaction does not employ a key pair during the transaction, but an identifier is still
desired/required for that party, then a non-null identifier shall be selected/assigned in accordance
with the requirements of the protocol relying upon the transaction.
Owner
generates Obtain
Key Pair
TTP (6.3)
generates
Owner obtains
Assurance of
Key Pair Validity
(6.4.1)
Provide
Assurance of Possession
and Identifier to a
Binding Authority
16
4.2 Key-Agreement Process
Figure 2 depicts the steps implemented by an entity when establishing secret keying material
with another entity using one of the key-agreement schemes described in this Recommendation.
(Some discrepancies in ordering may occur in practice, depending on the communication
protocol in which the key-agreement process is performed.) Note that some of the actions shown
may not be a part of every scheme. For example, key confirmation is not provided in the basic
key-agreement schemes (see Sections 8.2.2 and 8.3.2). The specifications of this
Recommendation indicate when a particular action is required.
17
Each participant obtains the identifier associated with the other entity, and verifies that the
identifier of the other entity corresponds to the entity with whom the participant wishes to
establish secret keying material.
Each entity that requires the other entitys public key for use in the key-agreement scheme
obtains a public key that has a trusted association with the other partys identifier, and obtains
assurance of the validity of the public key. Approved methods for obtaining assurance of the
validity of another entitys public key are provided in Section 6.4.2.
Each entity generates either a (random) secret value or a nonce, as required by the particular key-
agreement scheme. If the scheme requires an entity to generate a secret value, that secret value is
generated as specified in Section 5.3 and encrypted using the other entity's public key. The
resulting ciphertext is then provided to the other entity. If the key-agreement scheme requires
that an entity provide a nonce, that nonce is generated as specified in Section 5.4 and provided
(in plaintext form) to the other party. (See Sections 8.2 and 8.3 for details).
Each participant in the key-agreement process uses the appropriate public and/or private keys to
establish a shared secret (Z) as specified in Section 8.2.2 or 8.3.2. Each participant then derives
secret keying material from the shared secret (and other information), as specified in Section 5.5.
If the key-agreement scheme includes key confirmation provided by one or both of the
participants, then key confirmation is performed as specified in Section 8.2.3 or 8.3.3. When
performed in accordance with those sections, successful key confirmation may also provide
assurance that a key-pair owner possesses the (correct) private key (see Section 6.4.2.3.2).
The owner of any key pair used during the key-agreement transaction is required to have
assurance that the owner is in possession of the correct private key. Likewise, the recipient of
another entitys public key is required to have assurance that its owner is in possession of the
corresponding private key. Assurance of private-key possession is obtained prior to using the
derived keying material for purposes beyond those of the key-agreement transaction itself. This
assurance may be provided/obtained either through key confirmation, or by some other
approved means (see Sections 6.4.1 and 6.4.2).
18
material directly (as specified in Section 9.2.3) or employs a combination of secret value
encapsulation and key wrapping (as specified in Section 9.3.3). The resulting ciphertext is
transported to the receiver.
Prior to participating in a key-establishment transaction, the receiver is required to have
assurance of the validity of its own key pair. This assurance may be renewed whenever desired.
Upon (or before) receipt of the transported ciphertext, the receiver retrieves the private key from
its own key pair. Using its private key, the receiver takes the necessary steps (as specified in
Section 9.2.3 or 9.3.3) to decrypt the ciphertext and obtain the transported plaintext keying
material.
19
5 Cryptographic Elements
This section describes the basic cryptographic elements that support the development of key-
establishment schemes specified in this Recommendation.
20
MacData represents the data on which the MAC tag is computed. The minimum length of
MacKey is specified in Section 5.6.3.
MacKey is obtained from the DerivedKeyingMaterial (when a key-agreement scheme
employs key confirmation) or obtained from the TransportedKeyingMaterial (when a key-
transport scheme employs key confirmation), as specified in Section 5.6.1.1.
The resulting MAC consists of MacBitLen bits, which is the full output length of the selected
MAC algorithm.
2. The MacBitLen bits are input to a truncation function TMacTagBits to obtain the most significant
(i.e., leftmost) MacTagBits bits, where MacTagBits represents the intended length of the
MacTag, which is required to be less than or equal to MacBitLen. (When MacTagBits equals
MacBitLen, TMacTagBits acts as the identity function.) The minimum value for MacTagBits is
specified in Section 5.6.3.
Note: A routine implementing a MacTag computation for key confirmation shall destroy any
local copies of MacKey and MacData, any locally stored portions of MacTag, and any other
locally stored values used or produced during the execution of the routine; their destruction shall
occur prior to or during any exit from the routine whether exiting early because of an error or
exiting normally, with the output of MacTag.
5.4 Nonces
A nonce is a time-varying value that has (at most) a negligible chance of repeating. This
Recommendation requires party V to supply a nonce, NV, during the execution of key-agreement
schemes in the KAS1 family (see Section 8.2). This nonce is included in the input to the key-
derivation process, and (when key confirmation is employed) is also used in the computation of
the MAC tag sent from party V to party U.
21
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 (detail) so that it is different each time it is used.
3. A monotonically increasing sequence number, or
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 sequence number
is appended that will not repeat during a particular day.)
For the KAS1 schemes, the required nonce NV should be a random nonce, including a
component that consists of a random bit string that is generated anew for each transaction using
an approved random bit generator (RBG). For conformance with this Recommendation, the
security strength (in bits) supported by the instantiation of this RBG shall be at least 112 bits for
use with a 2048-bit RSA modulus, and shall be at least 128 bits for use with a 3072-bit RSA
modulus. For use with a 2048-bit RSA modulus, the length in bits of the random bit string
incorporated into the random nonce shall be at least 112 bits, but should be at least 224 bits. For
use with a 3072-bit RSA modulus, the length in bits of the random bit string incorporated into
the random nonce shall be at least 128 bits, but should be at least 256 bits. 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 agents
trusted to act on their behalf should determine that the components selected for inclusion in
required nonces meet the security requirements of those users or agents. The application tasked
with performing key establishment on behalf of a party should determine whether or not to
proceed with a 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
When employed during the execution of a key-establishment scheme as specified in this
Recommendation, the agreed-upon key-derivation method uses input that includes a freshly
created shared secret Z along with other information. The derived keying material shall be
computed in its entirety before outputting any portion of it, and (all copies of) Z shall be
destroyed immediately following its use. The output produced by the key-derivation method
shall only be used as secret keying material such as a symmetric key used for key wrapping,
data encryption, or message integrity; a secret initialization vector; or, perhaps, a master (key-
derivation) key that will be used to generate additional keying material (possibly using a
different process) (see [SP 800-108]). Non-secret keying material (such as a non-secret
initialization vector) shall not be generated from input that includes the shared secret Z.
23
3. salt: a (secret or non-secret) byte string that is only required when an HMAC-based
auxiliary function is implemented (see Option 2 above). The salt could be, for example,
a value computed from nonces exchanged as part of a key-establishment protocol that
employs one or more of the key-agreement schemes specified in this Recommendation, a
value already shared by the protocol participants, or a value that is pre-determined by the
protocol. The length of the salt can be any agreed-upon length. However, if there is no
means of selecting the salt, then it shall be an all-zero byte string whose bit length equals
the length of the input block for the hash function, hash.
Input:
1. Z: a byte string that represents the shared secret.
2. KBits: An integer that indicates the length (in bits) of the secret keying material to be
derived; KBits shall be less than or equal to hBits (232 1).
3. OtherInfo: A bit string of context-specific data (see Section 5.5.1.2 for details).
Process:
1. reps = KBits / hBits .
2. If reps > (232 1), then output an error indicator, and exit this process without performing
the remaining actions.
3. Initialize a 32-bit, big-endian bit string counter as 0000000116 (i.e. 0x00000001).
4. If counter || Z || OtherInfo is more than max_H_inputBits bits long,
then output an error indicator, and exit this process without performing the remaining
actions.
5. For i = 1 to reps by 1, do the following:
5.1 Compute K(i) = H(counter || Z || OtherInfo).
5.2 Increment counter (modulo 232), treating it as an unsigned 32-bit integer.
6. Let K_Last be set to K(reps) if (KBits / hBits) is an integer; otherwise, let K_Last be set to
the (KBits mod hBits) leftmost bits of K(reps).
7. Output DerivedKeyingMaterial = K(1) || K(2) || || K(reps-1) || K_Last.
Output:
The bit string DerivedKeyingMaterial (of length KBits bits), or an error indicator.
Errors:
1. The intended bit length of the derived keying material (as specified by KBits) is too long.
2. The bit string Z || OtherInfo (when prepended with a 32-bit counter) is too long.
Notes: When an approved key-establishment scheme employs this single-step KDF and
OtherInfo is used, the participants shall know which entity is acting as party U and which
entity is acting as party V to ensure (among other things) that they will derive the same
24
keying material. (See Sections 8 and 9 for descriptions of the specific actions required of
parties U and V during the execution of each of the approved key-establishment schemes
that use a key-derivation method.) The roles of parties U and V shall be assigned to the key-
establishment participants by the protocol employing the key-establishment scheme.
In step 5.1 above, the entire output of the hash function hash shall be used, whether H(x) =
hash(x) or H(x) = HMAC-hash(salt, x). Therefore, the bit length of each output block of H is
hBits bits. Some of the approved hash functions (see Section 5.1) are defined with an
internal truncation operation (e.g., SHA-384). In these cases, the entire output of hash is
the output value (e.g., for SHA-384, the entire output is defined to be the 384 bits resulting
from the internal truncation, so hBits = 384, in this case). Any truncation performed by the
KDF (external to hash) is done in step 6 above.
5.5.1.2 OtherInfo
The bit string OtherInfo should be used to ensure that the derived keying material is adequately
bound to the context of the key-establishment 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 the derived
keying material to the transaction context could adversely affect the types of assurance that can
be provided by certain key-agreement schemes.
Context-specific information that may be appropriate for inclusion in OtherInfo:
- Public information about parties U and V, such as their identifiers.
- The public keys contributed by each party to the key-establishment transaction. (One
could, for example, 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 secret data already shared by parties U and
V.
- An indication of the protocol or application employing the key-derivation method.
- Protocol-related information, such as a label or session identifier.
- The desired length of the derived keying material.
- An indication of the key-establishment scheme and/or key-derivation method used.
- An indication of various parameter or primitive choices (e.g., hash functions, MAC
tag lengths, 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.
For rationale in support of including entity identifiers, scheme identifiers, and/or other
information in OtherInfo, see Appendix B of [SP 800-56A]
If OtherInfo is used, the meaning of each information item and each items position within the
OtherInfo bit string shall be specified. In addition, each item of information included in
OtherInfo shall be unambiguously represented. For example, OtherInfo could take the form of a
fixed-length bit string, or, if greater flexibility is needed, OtherInfo could be represented in a
Datalen || Data format, 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 can be satisfied, for example, by using ASN.1 DER encoding as specified in
5.5.1.2.2 for OtherInfo.
25
Recommended formats for OtherInfo are specified in Sections 5.5.1.2.1 and 5.5.1.2.2. One of
these two formats should be used by the single-step KDF specified in Section 5.5.1.1 when the
auxiliary function employed is H = hash. When OtherInfo 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 to 112 are to be used as a 112-bit HMAC
key and that bits 113 to 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 item of
information. This subfield could also include information about the public key (if any)
contributed to the key-establishment transaction by party U. Although the schemes specified
in the Recommendation do not require the contribution of a nonce by party U, any nonce
provided by party U should 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 item of
information. This subfield could also include information about the public key(s) contributed
to the key-establishment transaction by party V. When this KDF is used in a KAS1 scheme
(see Section 8.2), the nonce, NV, supplied by party V shall be included in this field.
SuppPubInfo: An optional subfield that contains additional, mutually known public
information (e.g., KBits, an identifier for the particular key-establishment scheme that was
used to determine 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-establishment
transaction can vary). While an implementation may be capable of including 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 secret symmetric key that has been communicated through a separate
channel). While an implementation may be capable of including this subfield, the subfield
may be null for a given transaction.
26
Each of the three required subfields AlgorithmID, PartyUInfo, and PartyVInfo shall be the
concatenation 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 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. (In this variable-length format, a null string of data shall
be represented by a zero value for Datalen, indicating the absence of following data.) A protocol
using this format for OtherInfo shall specify the number, ordering and meaning of the
information-bearing substrings that are included in each of the subfields AlgorithmID,
PartyUInfo, and PartyVInfo, and shall also specify which of the two formats (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 KDF) shall be the concatenation of a pre-determined 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 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; the use of this form for the information allows U and V to omit a particular
information item without confusion about the meaning of the other information that is provided
in the SuppPrivInfo or SuppPubInfo subfield. The substrings representing items of information
that parties U and V choose not to 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
OtherInfo subfield SuppPrivInfo and/or the subfield SuppPubInfo, then the protocol shall specify
the number, ordering and meaning of additional items of information that may be used in the
allowed subfield(s) and shall specify the fixed-length of the Datalen counters.
27
in Section 5.5.1.1). This Recommendation makes no statement as to the adequacy of other
formats.
28
For key confirmation to comply with this Recommendation, key confirmation shall be
incorporated into an approved key-establishment scheme as specified in the sections that follow.
If any other methods are used to provide key confirmation, this Recommendation makes no
statement as to their adequacy.
29
party U or party V, as long as the KC provider, P, contributes a key pair to the key-establishment
transaction. The key-confirmation recipient, R, is the other party.
1. The provider, P, computes
MacDataP = message_stringP || IDP || IDR || EphemDataP || EphemDataR {|| TextP}
where
- message_stringP is a six-byte character string, with a value of KC_1_U when party
U is providing the MAC tag, or KC_1_V when party V is providing the MAC tag.
(Note that these values will be changed for bilateral key confirmation, as specified in
Section 5.6.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 contributed by the KC provider
and recipient, respectively. These values are specified in the sections describing the
schemes that include key confirmation.
- TextP is an optional bit string that may be used during key confirmation and that is
known by both parties.
The content of each of the components that are concatenated to form MacDataP shall be
precisely defined and unambiguously represented. A particular components 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 encoding of 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.
MacData shall include a non-null identifier, IDP, for the key-confirmation provider.
Depending upon the circumstances, the key-confirmation recipients identifier, IDR,
may be replaced by a null string. The rules for selecting IDP and IDR are as follows:
As specified in this Recommendation, the key-confirmation provider must own a key pair
that is employed by the basic key-establishment scheme (KAS1-basic, KAS2-basic,
KTS-OAEP-basic, or KTS-KEM-KWS-basic) that determines the MacKey value used in the
key-confirmation computations performed during the transaction. The identifier, IDp,
included in MacDataP shall be one that has a trusted association with the public key of
that key pair.
If the key-confirmation recipient also owns a key pair that is employed by the basic key-
establishment scheme used during the transaction, then the identifier, IDR, included in
MacDataP shall be one that has a trusted association with the public key of that key pair.
If the key-confirmation recipient does not own a key pair employed for key-establishment
30
purposes, and no identifier has been used to label that party during the execution of the basic
key-establishment scheme employed by the transaction, then IDR may be replaced by a null
string. However, if an identifier is desired/required for that party for key confirmation
purposes, then a non-null value for IDR, shall be selected/assigned in accordance with the
requirements of the protocol relying upon the transaction.
2. Whenever a particular identifier has been used to label the key-confirmation recipient
or key-confirmation provider in the execution of the basic key-establishment scheme used
during the transaction, that same identifier shall be used as IDP or IDR, respectively, in the
MacDataP used during key confirmation. For example, if party U is the key-confirmation
recipient, and IDU has been used to label party U in the OtherInfo employed by the key-
derivation method of a key-agreement scheme used during the transaction, then the
MacDataP used during key confirmation shall have IDR = IDU.
In the case of a key-agreement scheme: After computing the shared secret Z and applying the
key-derivation function to obtain the derived keying material, DerivedKeyingMaterial (see
Section 5.5), the KC provider uses agreed-upon bit lengths to parse DerivedKeyingMaterial
into two parts, MacKey and KeyData:
31
Note: The key-confirmation routines employed by the KC provider and KC recipient shall
destroy all local copies of MacKey, KeyData, MacData, and any other locally stored values used
or produced during their execution. Their destruction shall occur prior to or during any exit from
those routines whether exiting normally or exiting early, because of an error.
Unilateral key confirmation, as specified in this Recommendation, can be incorporated into any
key-establishment scheme in which the key-confirmation provider is required to own a key-
establishment key pair that is used in the key-establishment process. Unilateral key confirmation
may be added in either direction to a KAS2 scheme (see Sections 8.3.3.2 and 8.3.3.3); it may
also be added to a KAS1, KTS-OAEP, or KTS-KEM-KWS scheme, but only with party V (the
party contributing the key pair) acting as the key-confirmation provider, and party U acting as
the key-confirmation recipient (see Sections 8.2.3.1, 9.2.4.2, and 9.3.4.2).
32
approved hash function or AES CMAC [SP 800-38B] with a key length of 128, 192, or 256 bits
(see Section 5.2). MacKey shall be at least 112 bits in length when a 2048-bit RSA modulus is
used during the transaction, and at least 128 bits in length when a 3072-bit modulus is used. The
bit length of MacTag shall be at least 64 bits for key-confirmation in this Recommendation. For
other applications, please refer to the relevant specifications for the minimum length required for
message authentication codes.
In cases where key confirmation is incorporated in a key-transport scheme as specified in this
Recommendation, the method used to generate the MAC key that is included in the transported
keying material shall comply with the methods specified in [SP 800-133] for generating
symmetric keys. The MAC key and MAC algorithm shall be capable of supporting at least a
112-bit security strength when a 2048-bit RSA modulus is used during the transaction, and of
supporting at least a 128-bit security strength when a 3072-bit modulus is used.
33
(see Section 6.3), consistent with the criteria of Section 6.2; assurance of private and
public-key validity; and assurance of pair-wise consistency.
7. A recipient of a public key shall have assurance of the validity of the public key (see
Section 6.4.2.1). 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.
8. A recipient of a public key shall have assurance of the owners possession of the
associated private key (see Section 6.4.2.3). This assurance may be provided, for
example, through the use of a public key certificate if the CA obtains sufficient assurance
of possession as part of its certification process.
2. The public exponent e shall be an odd integer that is selected prior to the generation of p
and q such that:
65 537 e < 2256
3. The prime factors p and q shall be generated using one of the methods specified in
Appendix B.3 of [FIPS 186] such that:
6.2.2 Formats
The RSA private key may be expressed in several formats. The basic format of the RSA private
key consists of the modulus n and a private-key exponent d that depends on n and the public-key
exponent e; this format is used throughout this Recommendation. The other two formats may be
used in implementations, but may require appropriate modifications for correct implementation.
To facilitate implementation testing, the format for the private key shall be one of the following:
1. The basic format: (n, d).
34
2. The prime-factor format: (p, q, d).
3. The Chinese Remainder Theorem (CRT) format: (n, e, d, p, q, dP, dQ, qInv), where dP =
d mod (p 1), dQ = d mod (q 1), and qInv = q1 mod p.
Key-pair generators and key-pair validation methods are given for each of these formats in
Sections 6.3 and 6.4, respectively.
The key pairs employed by the key-establishment schemes specified in this Recommendation
shall be generated using the techniques specified in Appendix B.3 of [FIPS 186], employing the
requisite methods for prime-number generation, primality testing, etc., that are specified in
Appendix C of that document.
An approved RSA key-pair generator shall be used to produce a random RSA key pair with a
modulus length of either 2048 or 3072 bits, possibly using other inputs during the process. Key-
pair generators require the use of an approved random bit generator (RBG). See Section 5.3.
The approved RSA key-pair generators provided in Sections 6.3.1 and 6.3.2 are differentiated
by the method for determining the public-key exponent e that is used as part of an RSA public
key (i.e., (n, e)); Section 6.3.1 addresses the use of a fixed value for the exponent, whereas
Section 6.3.2 uses a randomly generated value.
6.3.1 RSAKPG1 Family: RSA Key-Pair Generation with a Fixed Public Exponent
The RSAKPG1 family of key-pair generation methods consists of three RSA key-pair generators
where the public exponent has a fixed value (see Section 6.2).
Three representations are addressed:
1. rsakpg1-basic generates the private key in the basic format (n, d),
2. rsakpg1-prime-factor generates the private key in the prime-factor format (p, q, d), and
3. rsakpg1-crt generates the private key in the Chinese Remainder Theorem format (n, e, d,
p, q, dP, dQ, qInv).
An implementation may perform a key-pair validation before outputting the key pair from the
generator. The key-pair validation methods for this family are specified in Section 6.4.1.2.
6.3.1.1 rsakpg1-basic
rsakpg1-basic is the generator in the RSAKPG1 family where the private key is in the basic
format (n, d).
35
2. nBits: the intended length in bits of the RSA modulus; and
3. e: a fixed public exponent an odd integer, such that 65 537 e < 2256.
Process:
1. Check the values:
a. If s is not the integer 112 or 128, output an indication that the security strength
is incorrect, and exit without further processing.
b. If s =112 and nBits 2048, or if s =128 and nBits 3072, output an indication
that the modulus length is incorrect, and exit without further processing.
c. If e is not an odd integer such that 65 537 e < 2256, output an indication that
the exponent is out of range, and exit without further processing.
2. Generate the prime factors p and q, as specified in [FIPS 186].
3. Determine the private exponent d:
d = e1 mod LCM(p 1, q 1) .
In the event that no such d exists, or in the very rare event that 2/2 , discard the
results of all computations and repeat the process, starting at step 2.
5. Perform a pair-wise consistency test by verifying that k = (ke)d mod n for some integer k
satisfying 1 < k < n-1. If an inconsistency is found, output an indication of a pair-wise
consistency failure, and exit without further processing.
6. Output (n, e) as the public key, and (n, d) as the private key.
Output:
36
Note that key-pair validation, as specified in Section 6.4.1.2.1, can be performed after step 5 and
before step 6. If an error is detected, output an indication of a key-pair validation failure, and exit
without further processing.
A routine that implements this generation function shall destroy any local copies of p, q, and d,
as well as any other locally stored values used or produced during its execution. Their
destruction shall occur prior to or during any exit from the routine (whether exiting early,
because of an error, or exiting normally, with the output of an RSA key pair). Note that the
requirement for destruction includes any locally stored portions of the output key pair.
6.3.1.2 rsakpg1-prime-factor
rsakpg1-prime-factor is the generator in the RSAKPG1 family where the private key is in the
prime factor format (p, q, d).
Function call: rsakpg1-prime-factor(s, nBits, e)
The inputs, outputs and errors are the same as in rsakpg1-basic (see 6.3.1.1), except that the
private key is in the prime-factor format: (p, q, d).
The steps are the same as in rsakpg1-basic, except that processing Step 6 is replaced by the
following:
6. Output (n, e) as the public key, and (p, q, d) as the private key.
Note that key-pair validation, as specified in Section 6.4.1.2.2, can be performed after step 5 and
before step 6. If an error is detected, output an indication of a key-pair validation failure, and exit
without further processing.
A routine that implements this generation function shall destroy any local copies of p, q, and d,
as well as any other locally stored values used or produced during its execution. Their
destruction shall occur prior to or during any exit from the routine (whether exiting early,
because of an error, or exiting normally, with the output of an RSA key pair). Note that the
requirement for destruction includes any locally stored portions of the output key pair.
6.3.1.3 rsakpg1-crt
rsakpg1-crt is the generator in the RSAKPG1 family where the private key is in the Chinese
Remainder Theorem format (n, e, d, p, q, dP, dQ, qInv).
Function call: rsakpg1-crt(s, nBits, e)
The inputs, outputs and errors are the same as in rsakpg1-basic (see 6.3.1.1), except that the
private key is in the Chinese Remainder Theorem format: (n, e, d, p, q, dP, dQ, qInv).
The steps are the same as in rsakpg1-basic, except that processing steps 5 and 6 are replaced by
the following:
5. Determine the components dP, dQ and qInv:
a. dP = d mod (p 1).
b. dQ = d mod (q 1).
37
c. qInv = q1 mod p.
6. Perform a pair-wise consistency test by verifying that k = (ke)d mod n for some integer k
satisfying 1 < k < n-1. If an inconsistency is found, output an indication of a pair-wise
consistency failure, and exit without further processing.
7. Output (n, e) as the public key, and (n, e, d, p, q, dP, dQ, qInv) as the private key.
Note that key-pair validation, as specified in Section 6.4.1.2.3, can be performed after step 6 and
before step 7. If an error is detected, output an indication of a key-pair validation failure, and exit
without further processing.
A routine that implements this generation function shall destroy any local copies of p, q, dP, dQ,
qInv, and d, as well as any other locally stored values used or produced during its execution.
Their destruction shall occur prior to or during any exit from the routine (whether exiting early,
because of an error, or exiting normally, with the output of an RSA key pair). Note that the
requirement for destruction includes any locally stored portions of the output key pair.
2. rsakpg2-prime-factor generates the private key in the prime factor format (p, q, d), and
3. rsakpg2-crt generates the private key in the Chinese Remainder Theorem format (n, e, d,
p, q, dP, dQ, qInv).
An implementation may perform a key-pair validation before outputting the key pair from the
generation function. The key-pair validation methods for this family are specified in Section
6.4.1.3.
6.3.2.1 rsakpg2-basic
rsakpg2-basic is the generator in the RSAKPG2 family where the private key is in the basic
format (n, d).
Function call: rsakpg2-basic(s, nBits, eBits)
Input:
1. s: the target security strength;
3. eBits: the intended length in bits of the public exponent an integer such that 17 eBits
256. Note that the public exponent shall be an odd integer, such that 65 537 e < 2256.
38
Process:
1. Check the values:
a. If s is not the integer 112 or 128, output an indication that the security strength
is incorrect, and exit without further processing.
b. If s =112 and nBits 2048, or if s =128 and nBits 3072, output an indication
that the modulus length is incorrect, and exit without further processing.
c. If eBits is not an integer such that 17 eBits 256, output an indication that
the exponent length is out of range, and exit without further processing.
2. Generate an odd public exponent e in the range [2eBits 1 + 1, 2eBits 1] using an approved
RBG that supports a minimum security strength of s bits (see Section 5.3).
In the event that no such d exists, or in the very rare event that 2/2 , discard the
results of all computations and repeat the process, starting at step 2.
6. Perform a pair-wise consistency test by verifying that k = (ke)d mod n for some integer k
satisfying 1 < k < n-1. If an inconsistency is found, output an indication of a pair-wise
consistency failure, and exit without further processing.
7. Output (n, e) as the public key, and (n, d) as the private key.
Output:
39
Note that key-pair validation, as specified in Section 6.4.1.3.1, can be performed after step 6 and
before step 7. If an error is detected, output an indication of a key-pair validation failure, and exit
without further processing.
A routine that implements this generation function shall destroy any local copies of p, q, and d,
as well as any other locally stored values used or produced during its execution. Their
destruction shall occur prior to or during any exit from the routine (whether exiting early,
because of an error, or exiting normally, with the output of an RSA key pair). Note that the
requirement for destruction includes any locally stored portions of the output key pair.
6.3.2.2 rsakpg2-prime-factor
rsakpg2-prime-factor is the generator in the RSAKPG2 family where the private key is in the
prime-factor format (p, q, d).
Function call: rsakpg2-prime-factor(s, nBits, eBits)
The inputs, outputs and errors are the same as in rsakpg2-basic (see 6.3.2.1), except that the
private key is in the prime-factor format: (p, q, d).
The steps are the same as in rsakpg2-basic, except that processing Step 7 is replaced by the
following:
7. Output (n, e) as the public key, and (p, q, d) as the private key.
Note that key-pair validation as specified in Section 6.4.1.3.2 can be performed after step 6 and
before step 7. If an error is detected, output an indication of a key-pair validation failure, and exit
without further processing.
A routine that implements this generation function shall destroy any local copies of p, q, and d,
as well as any other locally stored values used or produced during its execution. Their
destruction shall occur prior to or during any exit from the routine (whether exiting early,
because of an error, or exiting normally, with the output of an RSA key pair). Note that the
requirement for destruction includes any locally stored portions of the output key pair.
6.3.2.3 rsakpg2-crt
rsakpg2-crt is the generator in the RSAKPG2 family where the private key is in the Chinese
Remainder Theorem format (n, e, d, p, q, dP, dQ, qInv).
Function call: rsakpg2-crt(s, nBits, eBits)
The inputs, outputs and errors are the same as in rsakpg2-basic (see 6.3.2.1), except that the
private key is in the Chinese Remainder Theorem format: (n, e, d, p, q, dP, dQ, qInv).
The steps are the same as in rsakpg2-basic, except that processing Steps 6 and 7 are replaced by
the following:
6. Determine the components dP, dQ and qInv:
a. dP = d mod (p 1).
40
b. dQ = d mod (q 1).
c. qInv = q1 mod p.
7. Perform a pair-wise consistency test by verifying that k = (ke)d mod n for some integer k
satisfying 1 < k < n-1. If an inconsistency is found, output an indication of a pair-wise
consistency failure, and exit without further processing.
8. Output (n, e) as the public key, and (n, e, d, p, q, dP, dQ, qInv) as the private key.
Note that key-pair validation as specified in Section 6.4.1.3.3 can be performed after step 7 and
before step 8. If an error is detected, output an indication of a key-pair validation failure, and exit
without further processing.
A routine that implements this generation function shall destroy any local copies of p, q, dP, dQ,
qInv, and d, as well as any other locally stored values used or produced during its execution.
Their destruction shall occur prior to or during any exit from the routine (whether exiting early,
because of an error, or exiting normally, with the output of an RSA key pair). Note that the
requirement for destruction includes any locally stored portions of the output key pair.
1
The trusted third party is trusted not to use or reveal the private keys.
41
the owner). Depending on an organizations requirements, a renewal of key-pair validity may be
prudent. The method of obtaining initial and renewed assurance of key-pair validity is addressed
in Section 6.4.1.1.
Assurance of key-pair validity can be renewed at any time (see Section 6.4.1.1). As time passes,
an owner may lose possession of the correct value of the private-key component of their key
pair, e.g. due to an error; for this reason, renewed (i.e., current) assurance of possession of a
private key can be of value for some applications. See Section 6.4.1.5 for techniques that the
owner can use to obtain renewed assurance of private-key possession separately from assurance
of key-pair validity.
42
owner. Note that if the key-pair validation is performed separately from the
key-pair generation, and the TTP does not have the key pair, then the party
that generated the key pair or owns the key pair must provide it to the TTP.
c. The TTP generated the key pair (with or without performing key-pair validation),
and the owner performs the key-pair validation The owner performs a key-pair
validation as specified in Section 6.4.1.4.
Note that the use of a TTP to generate a key pair or to perform key-pair validation for an owner
means that the TTP must be trusted (by both the owner and any recipient) to not use the owners
private key to masquerade as the owner or otherwise compromise the key-establishment
transaction.
The key pair can be revalidated at any time by the owner as follows:
A. Perform a pair-wise consistency test by verifying that k = (ke)d mod n for some integer k
satisfying 1 < k < n-1, and
B. Perform a successful key-pair validation:
1. If the intended value or length of the exponent is known, then perform a successful
key-pair validation as specified in Section 6.4.1.2 or 6.4.1.3.
2. If the intended value or length of the exponent is NOT known, then perform a
successful key-pair validation as specified in Section 6.4.1.4.
6.4.1.2.1 rsakpv1-basic
rsakpv1-basic is the key-pair validation method corresponding to rsakpg1-basic (see Section
6.3.1.1).
Function call: rsakpv1-basic (s, nBits, efixed, (npub, epub), (npriv, d))
Input:
1. s: the target security strength;
2. nBits: the expected length in bits of the RSA modulus;
3. efixed: the intended fixed public exponent an odd integer such that 65 537 efixed < 2256;
4. (npub, epub): the RSA public key to be validated; and
5. (npriv, d): the RSA private key to be validated in the basic format.
Process:
1. Check the ranges:
43
a. If s is not the integer 112 or 128, output an indication that the security strength is
incorrect, and exit without further processing.
b. If nBits is not the integer 2048 or 3072, output an indication that the modulus
length is incorrect, and exit without further processing.
c. If efixed is not an odd integer such that 65 537 efixed < 2256, output an indication
that the fixed exponent is out of range, and exit without further processing.
2. Compare the public exponents:
If epub efixed, output an indication that the request is invalid, and exit without further
processing.
3. Check the modulus:
a. If npub npriv, output an indication of an invalid key pair, and exit without further
processing.
b. If the length in bits of the modulus npub is not nBits, output an indication of an
invalid key pair, and exit without further processing.
4. Prime factor recovery:
a. Recover the prime factors p and q from the modulus npub, the public exponent
epub and the private exponent d (see Appendix C):
(p, q) = RecoverPrimeFactors (npub, epub, d)
b. If RecoverPrimeFactors outputs an indication that the prime factors were not
found, output an indication that the request is invalid, and exit without further
processing.
c. If npub pq, then output an indication that the request is invalid, and exit
without further processing.
5. Check the prime factors:
a. Apply an approved primality test to test the prime number p (see Appendix C.3
in [FIPS 186]).
b. If the primality test indicates that p is not prime, output an indication of an invalid
key pair, and exit without further processing.
c. If (p < 2(2nBits/2-1)) or (p > 2nBits/2 1), output an indication of an invalid key pair,
and exit without further processing.
d. If GCD (p 1, epub) 1, output an indication of an invalid key pair, and exit
without further processing.
e. Apply an approved primality test to test the prime number q (see Appendix C.3
in [FIPS 186]).
44
f. If the primality test indicates that q is not prime, output an indication of an invalid
key pair, and exit without further processing.
A routine that implements this validation function shall destroy any local copies of p, q and d, as
well as any other locally stored values used or produced during its execution. Their destruction
shall occur prior to or during any exit from the routine (whether exiting early, because of an
error, or exiting normally).
6.4.1.2.2 rsakpv1-prime-factor
rsakpv1-prime-factor is the key-pair validation method corresponding to rsakpg1-prime-factor
(see 6.3.1.2).
Function call: rsakpv1-prime-factor (s, nBits, efixed, (npub, epub), (p, q, d))
The inputs, outputs and errors are the same as in rsakpv1-basic (see Section 6.4.1.2.1), except
that the private key is in the prime-factor format: (p, q, d).
45
The steps are the same as in rsakpv1-basic except that in processing:
A. Step 3 is replaced by the following:
3. Check the modulus:
a. If npub pq, output an indication of an invalid key pair, and exit without further
processing.
b. If the length in bits of the modulus npub is not nBits, output an indication of an
invalid key pair, and exit without further processing.
B. Step 4 (prime factor recovery) is omitted.
A routine that implements this validation function shall destroy any local copies of p, q, and d, as
well as any other locally stored values used or produced during its execution. Their destruction
shall occur prior to or during any exit from the routine (whether exiting early, because of an
error, or exiting normally).
6.4.1.2.3 rsakpv1-crt
rsakpv1-crt is the key-pair validation method corresponding to rsakpg1-crt.
Function call: rsakpv1-crt (s, nBits, efixed, (npub, epub), (npriv, epriv, d, p, q, dP, dQ, qInv))
The inputs, outputs and errors are the same as in rsakpv1-basic (see Section 6.4.1.2.1), except
that the private key is in the Chinese Remainder Theorem format: (npriv, epriv, d, p, q, dP, dQ,
qInv).
The steps are the same as in rsakpv1-basic except that in processing:
A. Step 2 is replaced by the following:
2. Compare the public exponents:
If (epub efixed) or (epub epriv), output an indication of an invalid key pair, and exit
without further processing.
B. Step 3 is replaced by
3. Check the modulus:
a. If npub pq, or npub npriv, output an indication of an invalid key pair, and
exit without further processing.
b. If the length in bits of the modulus npub is not nBits, output an indication of
an invalid key pair, and exit without further processing.
C. Step 4 (prime factor recovery) is omitted,
D. Step 7 is replaced by the following:
7. Check the CRT components: Check that the components dP, dQ and qInv satisfy
a. 1 < dP < (p 1).
46
b. 1 < dQ < (q 1).
f. 1 = (qInv q) mod p .
If any of the criteria in Section 6.2.1 are not met, output an indication of an
invalid key pair, and exit without further processing.
8. Output an indication that the key pair is valid.
A routine that implements this validation function shall destroy any local copies of p, q, d, dP,
dQ, and qInv, as well as any other locally stored values used or produced during its execution.
Their destruction shall occur prior to or during any exit from the routine (whether exiting early,
because of an error, or exiting normally).
6.4.1.3.1 rsakpv2-basic
rsakpv2-basic is the validation method corresponding to rsakpg2-basic (see Section 6.3.2.1).
Function call: rsapkv2-basic (s, nBits, eBits, (npub, e), (npriv, d))
The method is the same as the rsapkv1-basic method in Section 6.4.1.2.1, except that:
A. The efixed input parameter becomes eBits, which is the expected length in bits of the
public exponent, an integer such that 17 eBits 256.
B. Step 1c is replaced by:
c. If (eBits < 17) or (eBits > 256), output an indication that the exponent is out of
range, and exit without further processing.
C. Step 2 is replaced by:
2. Check the public exponent.
If the public exponent epub is not odd, or if the length in bits of the public
exponent epub is not eBits, output an indication of an invalid key pair, and exit
without further processing.
A routine that implements this validation function shall destroy any local copies of p, q, and d, as
well as any other locally stored values used or produced during its execution. Their destruction
shall occur prior to or during any exit from the routine (whether exiting early, because of an
error, or exiting normally).
47
6.4.1.3.2 rsakpv2-prime-factor
rsakpv2-prime-factor is the key-pair validation method corresponding to rsakpg2-prime-factor
key-pair generation method (see Section 6.3.2.2).
Function call: rsakpv2-prime-factor (s, nBits, eBits, (npub, epub), (p, q, d))
The inputs, outputs and errors are the same as in rsakpv1-basic (see Section 6.4.1.2.1), except
that the private key is in the prime factor format: (p, q, d).
The steps are the same as in rsakpv1-basic (see Section 6.4.1.2.1), except that:
A. The efixed input parameter becomes eBits, which is the expected length in bits of the
public exponent, an integer such that 17 eBits 256.
B. Step 1c is replaced by:
c. If (eBits < 17) or (eBits > 256), output an indication that the exponent is out of
range, and exit without further processing.
C. Step 2 is replaced by:
2. Check the public exponent.
If the public exponent epub is not odd, or if the length in bits of the public
exponent epub is not eBits, output an indication of an invalid key pair, and exit
without further processing.
D. Step 3 is replaced by the following:
3. Check the modulus:
a. If npub pq, output an indication of an invalid key pair, and exit without
further processing.
b. If the length in bits of the modulus npub is not nBits, output an indication of
an invalid key pair, and exit without further processing.
E. Step 4 (prime factor recovery) is omitted.
A routine that implements this validation function shall destroy any local copies of p, q, and d, as
well as any other locally stored values used or produced during its execution. Their destruction
shall occur prior to or during any exit from the routine (whether exiting early, because of an
error, or exiting normally).
6.4.1.3.3 rsakpv2-crt
rsakpv2-crt is the key-pair validation method corresponding to rsakpg2-crt key-pair generation
method (see Section 6.3.1.3).
Function call: rsakpv2-crt (s, nBits, eBits, (npub, epub), (npriv, epriv, d, p, q, dP, dQ, qInv))
The inputs, outputs and errors are the same as in rsakpv1-basic (see Section 6.4.1.2.1), except
that the private key is in the Chinese Remainder Theorem format: (npriv, epriv, d, p, q, dP, dQ,
qInv).
48
The steps are the same as in rsakpv1-basic (see Section 6.4.1.2.1), except that:
A. The efixed input parameter becomes eBits, which is the expected length in bits of the
public exponent, an integer such that 17 eBits 256.
B. Step 1c is replaced by:
c. If (eBits < 17) or (eBits > 256), output an indication that the exponent is out of
range, and exit without further processing.
C. Step 2 is replaced by the following:
2. Compare the public exponents:
If (epub epriv) or (epub is not odd) or (length in bits of epub is not eBits), output an
indication of an invalid key pair, and exit without further processing.
D. Step 3 is replaced by
3. Check the modulus:
a. If (npub pq) or (npub npriv) output an indication of an invalid key pair,
and exit without further processing.
b. If the length in bits of the modulus npub is not nBits, output an indication of
an invalid key pair, and exit without further processing.
E. Step 4 (prime factor recovery) is omitted,
F. Step 7 is replaced by the following:
7. Check the CRT components: Check that the components dP, dQ and qInv satisfy
a) 1 < dP < (p 1).
f) 1 = (qInv q) mod p.
If any of the criteria in Section 6.2.1 are not met, output an indication of an
invalid key pair, and exit without further processing.
8. Output an indication that the key pair is valid.
A routine that implements this validation function shall destroy any local copies of p, q, d, dP,
dQ, and qInv, as well as any other locally stored values used or produced during its execution.
49
Their destruction shall occur prior to or during any exit from the routine (whether exiting early,
because of an error, or exiting normally).
6.4.1.4.1 basic-pkv
In this format, the private key is represented as (n, d).
Function call: basic_pkv (s, nBits, (npub, epub), (npriv, d))
The method is the same as the rsapkv1-basic method in Section 6.4.1.2.1, except that:
A. A value for efixed is not available as an input parameter.
B. Step 1.c is replaced by:
If epub is not an odd integer such that 65 537 epub < 2256, output an indication that the
fixed exponent is out of range, and exit without further processing.
C. Step 2 is not performed.
A routine that implements this validation function shall destroy any local copies of p, q, and d, as
well as any other locally stored values used or produced during its execution. Their destruction
shall occur prior to or during any exit from the routine (whether exiting early, because of an
error, or exiting normally).
6.4.1.4.2 prime-factor-pkv
In this format, the private key is represented as (p, q, d).
Function call: prime-factor_pkv (s, nBits, (npub, epub), (p, q, d))
The inputs, outputs and errors are the same as in rsakpv1-basic (see Section 6.4.1.2.1), except
that the private key is in the prime factor format: (p, q, d).
The steps are the same as in rsakpv1-basic (see Section 6.4.1.2.1), except that:
A. A value for efixed is not available as an input parameter.
B. Step 1.c is replaced by:
If epub is not an odd integer such that 65 537 epub < 2256, output an indication that the
fixed exponent is out of range, and exit without further processing.
C. Step 2 is not performed.
D. Step 3 is replaced by the following:
50
3. Check the modulus:
a. If npub pq, output an indication of an invalid key pair, and exit without
further processing.
b. If the length in bits of the modulus npub is not nBits, output an indication of
an invalid key pair, and exit without further processing.
E. Step 4 (prime factor recovery) is omitted.
A routine that implements this validation function shall destroy any local copies of p, q, and d, as
well as any other locally stored values used or produced during its execution. Their destruction
shall occur prior to or during any exit from the routine (whether exiting early, because of an
error, or exiting normally).
6.4.1.4.3 crt_pkv
In this format, the private key is represented as (n, e, d, p, q, dP. dQ, qInv).
Function call: crt_pkv(s, nBits, (npub, epub), (npriv, epriv, d, p, q, dP, dQ, qInv))
The inputs, outputs and errors are the same as in rsakpv1-basic (see Section 6.4.1.2.1), except
that the private key is in the Chinese Remainder Theorem (CRT) format: (npriv, epriv, d, p, q, dP,
dQ, qInv).
The steps are the same as in rsakpv1-basic (see Section 6.4.1.2.1), except that:
A. A value for efixed is not available as an input parameter.
B. Step 1c is replaced by:
If epub is not an odd integer such that 65 537 epub < 2256, output an indication that the
fixed exponent is out of range, and exit without further processing.
C. Step 2 is not performed.
D. Step 3 is replaced by
3. Check the modulus:
a. If (npub pq) or (npub npriv), output an indication of an invalid key pair,
and exit without further processing.
b. If the length in bits of the modulus npub is not nBits, output an indication of
an invalid key pair, and exit without further processing.
E. Step 4 (prime factor recovery) is omitted,
F. Step 7 is replaced by the following:
7. Check the CRT components: Check that the components dP, dQ and qInv satisfy
a) 1 < dP < (p 1).
51
c) 1 < qInv < p .
f) 1 = (qInv q) mod p.
If any of the criteria in Section 6.2.1 are not met, output an indication of an
invalid key pair, and exit without further processing.
8. Output an indication that the key pair is valid.
A routine that implements this validation function shall destroy any local copies of p, q, dP, dQ,
and qInv, as well as any other locally stored values used or produced during its execution. Their
destruction shall occur prior to or during any exit from the routine (whether exiting early,
because of an error, or exiting normally).
52
3. The owner receives assurance via an encrypted certificate - The key-pair owner uses the
private key while engaging in a key-establishment transaction with a Certificate
Authority (trusted by the owner) using a scheme in this Recommendation, after providing
the CA with the corresponding public key. As part of this transaction, the CA generates a
(new) certificate containing the owners public key and encrypts that certificate using
(some portion of) the symmetric keying material that has been established. Only the
encrypted form of the certificate is provided to the owner. By successfully decrypting the
certificate and verifying the CAs signature, the owner obtains assurance of possession of
the correct private key (at the time of the key-establishment transaction).
The key-pair owner (or agents trusted to act on the owners behalf) should determine that the
method used for obtaining renewed assurance of the owners possession of the correct private
key is sufficient and appropriate to meet the security requirements of the owners intended
application(s).
53
requirements as specified in this Recommendation. Plausibility tests can detect unintentional
errors with a reasonable probability. Note that full RSA public-key validation is not specified in
this Recommendation, as it is an area of research. Therefore, if an application requires assurance
of full public-key validation, then another approved key-establishment method shall be used.
Plausibility tests shall include the tests specified in SP 800-89 [SP 800-89], Section 5.3.3, with
the caveat that the length of the modulus shall be a length that is specified in this
Recommendation.
54
prohibit the parties to a key-establishment transaction from using a portion of the derived or
transported keying material during the key-establishment transaction for purposes required by
that key-establishment scheme. For example, in a transaction involving a key-agreement scheme
that incorporates key confirmation, the parties establish a (purported) shared secret, derive
keying material, and as part of that same transaction use a portion of the derived keying
material as the MAC key in their key-confirmation computations.
6.4.2.3.2 Recipient Obtains Assurance Directly from the Claimed Owner (i.e., the Other
Party)
The recipient of a public key can directly obtain assurance of the claimed owners current
possession of the corresponding private key by successfully completing a key-establishment
transaction that explicitly incorporates key confirmation, with the claimed owner serving as the
key-confirmation provider. Note that the recipient of the public key in question will also be the
key-confirmation recipient. Also note that this use of key confirmation is an additional benefit
beyond its use to confirm that two parties possess the same keying material.
There are a number of key-establishment schemes specified in this Recommendation that can be
used. In order to claim conformance with this Recommendation, the key-establishment
transaction during which the recipient of a public key seeks to obtain assurance of its owners
current possession of the corresponding private key shall employ one of the following approved
key-establishment schemes:
1. The KAS1-Party_V-confirmation scheme in Section 8.2.3.2 can be used to provide
assurance to party U that party V possesses the private key corresponding to party Vs
public key (PubKeyV) that is used during the key-agreement transaction.
2. The KAS2-Party_V-confirmation scheme in Section 8.3.3.2 can be used to provide
assurance to party U that party V possesses the private key corresponding to party Vs
public key (PubKeyV) that is used during the key-agreement transaction.
3. The KAS2-Party_U-confirmation scheme in Section 8.3.3.3 can be used to provide
assurance to party V that party U possesses the private key corresponding to party Us
public key (PubKeyU) that is used during the key-agreement transaction.
55
4. The KAS2-bilateral-confirmation scheme in Section 8.3.3.4 can be used to provide
assurance to each party that the other party possesses the private key corresponding to the
other partys public key that is used during the key-agreement transaction.
5. The KTS-OAEP-Party_V-confirmation scheme in Section 9.2.4.2 can be used to provide
assurance to party U (the key-transport sender) that party V (the key-transport receiver)
possesses the private key corresponding to party Vs public key (PubKeyV) that is used
during the key-transport transaction.
6. The KTS-KEM-KWS-Party_V-confirmation scheme in Section 9.3.4.2 can be used to
provide assurance to party U (the key-transport sender) that party V (the key-transport
receiver) possesses the private key corresponding to party Vs public-key (PubKeyV) that
is used during the key-transport transaction.
The recipient of a public key (or agents trusted to act on the recipients behalf) shall determine
whether or not using one of the key-establishment schemes in this Recommendation to obtain
assurance of possession through key confirmation is sufficient and appropriate to meet the
security requirements of the recipients intended application(s). Other approved methods (e.g.,
see Section 5.4.4 of SP 800-57-Part 1 [SP 800-57]) of directly obtaining this assurance of
possession from the owner are also allowed. If obtaining assurance of possession directly from
the owner is not acceptable, then assurance of possession shall be obtained indirectly as
discussed in Section 6.4.2.3.1.
Successful key confirmation (performed in the context described in this Recommendation)
demonstrates that the correct private key has been used in the key-confirmation providers
calculations, and thus also provides assurance that the claimed owner is the true owner.
The assurance of possession obtained via the key-confirmation schemes identified above may be
useful even when the recipient has previously obtained independent assurance that the claimed
owner of a public key is indeed its true owner. This may be appropriate in situations where the
recipient desires renewed assurance that the owner possesses the correct private key (and that the
owner is still able to use it correctly), including situations where there is no access to a trusted
party who can provide renewed assurance of the owners continued possession of the private
key.
7.1.1 RSAEP
RSAEP produces ciphertext using an RSA public key.
Function call: RSAEP((n, e), k)
Input:
56
1. (n, e): the RSA public key.
2. k: an integer such that 1 < k < n 1.
Assumption: The RSA public key is valid (see Section 6.4).
Process:
1. If k does not satisfy 1 < k < n 1, output an indication that k is out of range, and exit
without further processing.
3. Output c.
Output:
c: the ciphertext, an integer such that 1 < c < n 1, or an error indicator.
A routine that implements this primitive shall destroy any local copies of the input k, as well as
any other potentially sensitive locally stored values used or produced during its execution. Their
destruction shall occur prior to or during any exit from the routine (whether exiting early,
because of an error, or exiting normally, with the output of c).
7.1.2 RSADP
RSADP is the basic decryption primitive. It recovers plaintext from ciphertext using an RSA
private key.
Function call: RSADP((n, d), c)
Input:
1. (n, d): the RSA private key.
Process:
1. If the ciphertext c does not satisfy 1 < c < n 1, output an indication that the ciphertext is
out of range, and exit without further processing.
2. Let k = cd mod n.
3. Output k.
Output:
k: an integer such that 1 < k < n 1, or an error indicator.
Note:
Care should be taken to ensure that an implementation of RSADP does not reveal even
partial information about the value of k. An opponent who can reliably obtain particular bits
57
of k for sufficiently many chosen ciphertext values may be able to obtain the full decryption
of an arbitrary ciphertext by applying the bit-security results of Hstad and Nslund [HN
1998].
A routine that implements this primitive shall destroy any local copies of the input d, as well as
any other potentially sensitive locally stored values used or produced during its execution (such
as any locally stored portions of k). Their destruction shall occur prior to or during any exit from
the routine (whether exiting early, because of an error, or exiting normally, with the output of k).
Note that the requirement for destruction includes any locally stored portions of the output.
2. Generation:
58
a. Using the RBG (see Section 5.3), generate an nLen byte string, Z.
z = BS2I(Z, nLen).
3. RSA encryption:
a. Apply the RSAEP encryption primitive (see Section 7.1.1) to the integer z
using the public key (n, e) to produce an integer ciphertext c:
C = I2BS(c, nLen).
Output:
Z: the secret value to be shared (a byte string of length nLen bytes), and C: the ciphertext (a
byte string of length nLen bytes).
A routine that implements this operation shall destroy any locally stored portions of Z and z, as
well as any other potentially sensitive locally stored values used or produced during its
execution. Their destruction shall occur prior to or during any exit from the routine (whether
exiting early, because of an error, or exiting normally, with the output of Z and C). Note that the
requirement for destruction includes any locally stored portions of the secret value Z included in
the output.
59
2. Length checking:
If the length of the ciphertext C is not nLen bytes, output an indication of a decryption
error, and exit without further processing.
3. RSA decryption:
c = BS2I(C).
b. Apply the RSADP decryption primitive (see Section 7.1.2) to the ciphertext
c using the private key (n, d) to produce an integer z:
z = RSADP((n, d), c) .
d. Convert the integer z to a byte string Z of length nLen bytes (see Appendix
B.1):
Z = I2BS(z, nLen).
4. Output the string Z as the secret value (i.e., the shared secret), or an error indicator.
Output:
Z: the secret value/shared secret (a byte string of length nLen bytes), or an error indicator.
Note:
Care should be taken to ensure that an implementation does not reveal information about the
encapsulated secret value (i.e., the value of the integer z or its byte string equivalent Z). For
instance, the observable behavior of the I2BS routine should not reveal even partial
information about the byte string Z. An opponent who can reliably obtain particular bits of Z
for sufficiently many chosen ciphertext values may be able to obtain the full decryption of an
arbitrary RSA-encrypted value by applying the bit-security results of Hstad and Nslund
[HN 1998].
A routine that implements this operation shall destroy any local copies of the input d, any locally
stored portions of Z and z, and any other potentially sensitive locally stored values used or
produced during its execution. Their destruction shall occur prior to or during any exit from the
routine (whether exiting early, because of an error, or exiting normally, with the output of Z).
Note that the requirement for destruction includes any locally stored portions of the output.
60
RSAEP and RSADP primitives. These operations are used by the KTS-OAEP key-transport
schemes (see Section 9.2).
In the RSA-OAEP encryption operation, a data block is constructed by the sender (party U) from
the keying material to be transported and the hash of additional input (see Section 9.1) that is
shared by party U and the intended receiving party (party V). A random byte string is generated,
after which both the random byte string and the data block are masked in a way that binds their
values. The masked values are used to form the plaintext that is input to the RSAEP primitive,
along with the public key-establishment key of party V. The resulting RSAEP output further
binds the random byte string, the keying material and the hash of the additional data in the
ciphertext that is sent to party V.
In the RSA-OAEP decryption operation, the ciphertext and the receiving partys (i.e., party Vs)
private key-establishment key are input to the RSADP primitive, recovering the masked values
as output. The mask-generation function is then used to reconstruct and remove the masks that
obscure the random byte string and the data block. After removing the masks, party V can
examine the format of the recovered data and compare its own computation of the hash of the
additional data to the hash value contained in the unmasked data block, thus obtaining some
measure of assurance of the integrity of the recovered data including the transported keying
material.
RSA-OAEP can process up to nLen 2HLen 2 bytes of keying material, where nLen is the
length of the recipients RSA modulus in bytes (i.e., 256 or 384, in this Recommendation), and
HLen is the length (in bytes) of the values output by the underlying hash function.
61
For the purposes of this Recommendation, the MGF shall not be invoked more than once by
each party during a given transaction using a given MGF seed (i.e., a mask shall be derived only
once by each party from a given MGF seed).
Process:
1. If maskLen > 232 hashLen, output an error indicator, and exit from this process without
performing the remaining actions.
2. If mgfSeed is more than max_hash_inputLen bytes long, then output an error indicator,
and exit this process without performing the remaining actions.
Output:
The byte string mask (of length maskLen bytes), or an error indicator.
A routine that implements this function shall destroy any local copies of the input mgfSeed, any
locally stored portions of mask (e.g., any portion of T), and any other potentially sensitive locally
stored values used or produced during its execution. Their destruction shall occur prior to or
during any exit from the routine (whether exiting early, because of an error, or exiting normally,
with the output of mask). Note that the requirement for destruction includes any locally stored
portions of the output.
62
7.2.2.3 RSA-OAEP Encryption Operation
The RSA-OAEP.Encrypt operation produces a ciphertext from keying material and additional
input using an RSA public key, as shown in Figure 4. See Section 9.1 for more information on
the additional input. Let HLen be the length in bytes of the output of hash function H.
Function call: RSA-OAEP.ENCRYPT((n, e), K, A)
Input:
1. (n, e): the receivers RSA public key.
2. K: the keying material; a byte string of length at most nLen 2HLen 2, where nLen =
256 or 384 in this Recommendation.
3. A: additional input; a byte string (may be the empty string) to be cryptographically bound
to the keying material (see Section 9.1).
2. Length checking:
b. If KLen > nLen 2HLen 2, then output an indication that the keying
material is too long, and exit without further processing.
3. OAEP encoding:
HA = H(A).
c. Concatenate HA, PS, a single byte with a hexadecimal value of 01, and the
keying material K to form data DB of length nLen HLen 1 bytes as
follows:
DB = HA || PS || 01 || K,
63
d. Using the RBG (see Section 5.3), generate a random byte string mgfSeed of
length HLen bytes.
EM = 00 || maskedMGFSeed || maskedDB
4. RSA encryption:
em = BS2I(EM).
b. Apply the RSAEP encryption primitive (see Section 7.1.1) to the integer em
using the public key (n, e) to produce a ciphertext integer c:
C = I2BS(c, nLen).
Output: C: the ciphertext (a byte string of length nLen bytes), or an error indicator.
A routine that implements this operation shall destroy any local copies of sensitive input values
(e.g., K and any sensitive portions of A), as well as any other potentially sensitive locally stored
values used or produced during its execution (including HA, DB, mfgSeed, dbMask, maskedDB,
mgfSeedMask, maskedMGFSeed, EM, and em). Their destruction shall occur prior to or during
any exit from the routine whether exiting early, because of an error, or exiting normally, with
the output of C.
64
DB = HA PS 01 K
mgfSeed
MGF
MGF
EM = 00 maskedMGFSeed maskedDB
BS2I
RSAEP
I2BS
3. A: additional input; a byte string (may be the empty string) whose cryptographic binding
to the keying material is to be verified (see Section 9.1).
65
Assumptions: The RSA private key is valid.
Process:
1. Initializations:
a. nLen = the length of n in bytes. For this Recommendation, nLen = 256 or 384.
b. DecryptErrorFlag = False.
3. RSA decryption:
a. Apply the RSADP decryption primitive (see Section 7.1.2) to the ciphertext
integer c using the private key (n, d) to produce an integer em:
EM = I2BS(em, nLen).
4. OAEP decoding:
HA = Hash(A).
EM = Y || maskedMGFSeed || maskedDB.
66
mgfSeedMask = MGF(maskedDB, HLen).
g. Separate DB into a byte string HA of length HLen bytes and a byte string X
of length nLen 2HLen 1 bytes as follows:
DB = HA || X.
b. Otherwise, output K, the portion of the byte string X that follows the leading
01 byte.
Output:
K: the recovered keying material (a byte string of length at most nLen 2HLen 2 bytes), or
an error indicator.
A routine that implements this operation shall destroy any local copies of sensitive input values
(including d and any sensitive portions of A), any locally stored portions of K, and any other
potentially sensitive locally stored values used or produced during its execution (including
DecryptErrorFlag, em, EM, HA, Y, maskedMGFSeed , maskedDB, mgfSeedMask , mfgSeed ,
dbMask , DB, HA, and X). Their destruction shall occur prior to or during any exit from the
routine whether exiting because of an error, or exiting normally, with the output of K. Note that
the requirement for destruction includes any locally stored portions of the recovered keying
material.
Notes:
67
1. Care should be taken to ensure that the different error conditions that may be detected
in step 5 above cannot be distinguished from one another by an opponent, whether by
error message or by process timing. Otherwise, an opponent may be able to obtain
useful information about the decryption of a chosen ciphertext C, leading to the attack
observed by Manger in [Manger 2001]. A single error message should be employed
and output the same way for each type of decryption error. There should be no
difference in the observable behavior for the different RSA-OAEP decryption errors.
2. In addition, care should be taken to ensure that even if there are no errors, an
implementation does not reveal partial information about the encoded message em or
EM. For instance, the observable behavior of the mask-generation function should
not reveal even partial information about the MGF seed employed in the process
(since that could compromise portions of the maskedDB segment of EM). An
opponent who can reliably obtain particular bits of EM for sufficiently many chosen-
ciphertext values may be able to obtain the full decryption of an arbitrary ciphertext
by applying the bit-security results of Hstad and Nslund [HN 1998].
BS2I
RSADP
I2BS
EM = Y maskedMGFSeed maskedDB
MGF
MGF
DB = HA X
68
7.2.3 RSA-based Key-Encapsulation Mechanism with a Key-Wrapping Scheme
(RSA-KEM-KWS)
RSA-KEM-KWS is used by the KTS-KEM-KWS key-transport schemes (see Section 9.3). RSA-
KEM-KWS operations include a key-encapsulation method based on the RSASVE secret-value
encapsulation operations and an approved key-derivation method. These operations are used to
communicate a symmetric key-wrapping key to the intended receiving party. RSA-KEM-KWS
operations also include an approved symmetric key-wrapping method, which is used to convey
the actual keying material to the intended receiving party.
RSA-KEM-KWS can process keying material of any length supported by the key-wrapping
algorithm.
69
7.2.3.2.1 Key-Wrapping using CCM
The input to the CCM mode specified in SP 800-38C includes a nonce Nonce, additional input2
A and the keying material to be wrapped3 K; the additional input could be a null string.
See Appendix A.1 in [SP 800-38C] for restrictions on the (individual and combined) lengths of
the nonce, the additional input and the keying material to be wrapped.
Also required for the CCM mode is the length of the MAC tag to be produced 4 TBits; see
Appendix B.2 in [SP 800-38C] for guidance on the selection of the length of the MAC tag. The
wrapping operation encrypts the nonce, the additional input and the keying material to be
wrapped using a key-wrapping key5 KWK, resulting in C1, which includes the ciphertext
resulting from the encryption operation, together with a MAC tag of length TBits.
The additional input shall be available to both party U and party V (e.g., by an exchange of
information or using information already known by both parties). Information that may be
appropriate for inclusion in the additional input is discussed in Section 9.1.
Party U, who wraps the keying material, shall provide the nonce to the receiving party, party V.
Either party U and party V shall have agreed (in advance) on the MAC-tag length, or party U
shall send the MAC-tag length to party V, along with C1.
The key-wrapping operation using CCM is
Process:
1. If ((the length of KWK is not in the set {128, 192, 256}) OR (the value of TBits or the
lengths of Nonce, K and/or A are not considered valid for the CCM mode6)), then return
an error indicator, and exit without further processing.
2
Called associated data A in SP 800-38C.
3
Called the payload P in SP 800-38C.
4
Called Tlen in SP 800-38C.
5
Called K in SP 800-38C.
6
As specified in [SP 800-38C].
70
2. C1 = CCM.Encrypt(KWK, TBits, Nonce, K, A).
3. Return C1.
Output:
The ciphertext C1 (a byte string) or an error indicator.
Note that the inputs to the CCM.Encrypt operation in process step 2 do not exactly match the
specification of the Generation-Encryption process in [SP 800-38C], in which (the equivalents
of) KWK and TBits are listed as prerequisites, while the nonce, additional input and keying
material to be wrapped are listed as inputs.
A routine that implements this operation shall destroy any local copies of sensitive input values
(including KWK, K, and any sensitive portions of A), as well as any other potentially sensitive
locally stored values used or produced during its execution. (The CCM.Encrypt routine should
do the same.) Their destruction shall occur prior to or during any exit from the routine whether
exiting because of an error, or exiting normally, with the output of C1.
Process:
1. If ((the length of KWK is not in the set {128, 192. 256}) OR (the value of TBits, or the
lengths of Nonce, C1 and/or A are not considered valid for the CCM mode7)), then return
an error indicator, and exit without further processing.
2. (status, K) = CCM.Decrypt(KWK, TBits, Nonce, A, C1).
7
As specified in [SP 800-38C].
71
3. If (status indicates an error), return status, and exit without further processing.
4. Return K.
Output:
The plaintext keying material K (a byte string), or an error indicator.
Note that the inputs to the CCM.Decrypt operation in process step 2 do not exactly match the
specification of the Decryption-Verification process in [SP 800-38C], in which (the equivalents
of) KWK and TBits are listed as prerequisites, while the nonce, the additional input and C1 are
listed as inputs.
A routine that implements this operation shall destroy any local copies of sensitive input values
(including KWK and any sensitive portions of A), any locally stored portions of K, and any other
potentially sensitive locally stored values used or produced during its execution. (The
CCM.Decrypt routine should do the same.) Their destruction shall occur prior to or during any
exit from the routine whether exiting early, because of an error, or exiting normally, with the
output of K. Note that the requirement for destruction includes any locally stored portions of the
unwrapped (i.e., plaintext) keying material.
Process:
1. If the length of K is not valid, then return an error indicator and exit without further
processing.
2. C1 = Wrap(KWK, K).
3. Return C1.
8
Called the plaintext P in [SP 800-38F].
9
Called K in [SP 800-38C].
72
Output: The ciphertext C1, or an error indicator.
In process step 2, Wrap is either KW-AE or KWP-AE, as specified in [SP 800-38F].
Also, note that the inputs to the Wrap operation in step 2 do not exactly match the specification
for the KW and KWP wrapping methods in [SP 800-38F], in which KWK is listed as a
prerequisite, while K is listed as an input.
A routine that implements this operation shall destroy any local copies of the input values KWK
and K, as well as any other potentially sensitive locally stored values used or produced during its
execution. (The Wrap routine should do the same.) Their destruction shall occur prior to or
during any exit from the routine whether exiting because of an error, or exiting normally, with
the output of C1.
Process:
1. If the length of C1 is not valid, then return an error indicator, and exit without further
processing.
2. (status, K) = Unwrap(KWK, C1).
3. If (status indicates an error), return status, and exit without further processing.
4. Return K.
Output:
The plaintext keying material K, or an indication of an error.
In process step 2, Unwrap is either KW-AD or KWP-AD, as specified in [SP 800-38F].
Note that in process step 2, the returned values have been slightly altered from those specified in
[SP 800-38F]. In [SP 800-38F], either the plaintext key or a FAIL indicator is returned,
whereas process step 2 is specified with two return values: an indication of the status of the
operation (e.g., SUCCESS or FAIL) and the plaintext key if the Unwrap operation doesnt
indicate FAIL..
In addition, the inputs to the Unwrap operation in process step 2 do not exactly match the
specification in [SP 800-38F], in which KWK is listed as a prerequisite, while C1 is listed as an
input.
A routine that implements this operation shall destroy any local copies of the input value KWK,
any locally stored portions of K, and any other potentially sensitive locally stored values used or
73
produced during its execution (the Unwrap routine should do the same.) Their destruction shall
occur prior to or during any exit from the routine whether exiting early, because of an error, or
exiting normally, with the output of K. Note that the requirement for destruction includes any
locally stored portions of the unwrapped (i.e., plaintext) keying material.
6. A: The additional input (see Sections 7.2.3.2.1 and 9.1); a byte string (may be the
empty string).
7. OtherInfo: A bit string of context-specific data (see Section 5.5.1.2 for details).
2. Length checking:
74
Use the RSASVE.GENERATE operation specified in Section 7.2.1.2 to generate a secret-
value byte string Z and a corresponding RSA-ciphertext byte string C0 using party Vs
public key, where both Z and C0 are nLen bytes in length.
4. Key derivation:
Derive a key-wrapping key KWK of length kwkBits bits from the byte string Z
5. Key-wrapping:
Wrap the keying material K using the key-wrapping key KWK (see Section 7.2.3.2) to
produce a KWA-ciphertext byte string C1. Depending on the key-wrapping method used,
a nonce, the length of the MAC tag to be generated, and additional input are required,
although the additional input could be a null string (see Section 7.2.3.2).
6. Concatenation:
Concatenate the RSA-ciphertext byte string C0 and the KWA-ciphertext byte string C1 to
form a ciphertext byte string C:
C = C0 || C1.
Output:
The ciphertext C (a byte string), or an error indicator.
75
Figure 6: RSA-KEM-KWS Encryption Operation
7.2.3.4 RSA-KEM-KWS Decryption Operation
RSA-KEM-KWS.DECRYPT is illustrated in Figure 7. The private key-establishment key of the
intended receiving party (i.e., party V) and C0 are input to RSASVE.RECOVER, which returns the
secret value Z. This secret value (along with any required OtherInfo) is used as input to the key-
derivation method to recover the key-wrapping key. The key-wrapping key is then used to
decrypt C1 and recover the transported keying material. Depending on the key-wrapping method
used, a nonce, a MAC-tag length and additional input are also required for the process.
Function call: RSA-KEM-KWS.DECRYPT((n, d), C, kwkBits {, Nonce, TBits, A})
Input:
1. (n, d): the recipients RSA private key.
7. OtherInfo: A bit string of context-specific data (see Section 5.5.1.2 for details).
Assumptions: The RSA private key is valid, and the value of KBits is known.
76
Process:
1. nLen = the length of n in bytes, where nLen = 256 or 384 in this Recommendation.
2. Length checking:
b. If cLen nLen, or if cLen nLen is not consistent with the lengths supported
by the symmetric key-wrapping algorithm, output an indication of a
decryption error, and exit without further processing.
c. If kwkbits is not among the lengths appropriate for the block-cipher algorithm
used by the key-wrapping method, output an indication of a decryption error,
and exit without further processing.
3. Separation:
Separate the ciphertext byte string C into an RSA-ciphertext byte string C0 of length nLen
bytes and a KWA-ciphertext byte string C1 of length cLen nLen bytes:
C = C0 || C1.
4. Recover the secret value, which then becomes the shared secret:
Recover the secret-value byte string Z from the RSA-ciphertext byte string C0 using the
RSASVE.RECOVER operation specified in Section 7.2.1.3.
5. Key derivation:
Derive a key-wrapping key KWK of length kwkBits bits from the byte string Z
6. Key unwrapping:
Unwrap the KWA-ciphertext byte string C1 using the key-wrapping key KWK and,
depending on the key-wrapping method used, the nonce, MAC-tag length and additional
input needed to recover the keying material K (see Section 7.2.3.2), and verify the
correctness of A:
77
If the unwrapping operation outputs an error indicator, output an indication of a
decryption error, and exit without further processing.
Output:
The recovered keying material K (a byte string) that was wrapped, or an error indicator.
78
Figure 7: RSA-KEM-KWS Decryption Operation
8 Key-Agreement Schemes
In a key-agreement scheme, two parties, party U and party V, establish keying material over
which neither has complete control of the result, but both have influence. This Recommendation
provides two families of key-agreement schemes: KAS1 and KAS2. The KAS1 family consists
of the KAS1-basic and KAS1-Party_V-confirmation schemes, and the KAS2 family consists of
the KAS2-basic, KAS2-Party_V-confirmation, KAS2-Party_U-confirmation, and KAS2-
bilateral-confirmation schemes. These schemes are based on secret-value encapsulation (see
Section 7.2.1).
Key confirmation is included in some of these schemes to provide assurance that the participants
share the same keying material; see Section 5.6 for the details of key confirmation. When
possible, 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
other methods. Key confirmation may also provide assurance of private-key possession.
For both of the KAS1 and KAS2 schemes, Party V shall have an identifier, IDV, that has an
association with the key pair that is known (or discoverable) and trusted by party U (i.e., there
shall be a trusted association between IDV and party Vs public key). For the KAS2 key-
agreement schemes, party U shall also have such an identifier, IDU.
A general flow diagram is provided for each key-agreement scheme. The dotted-line arrows
represent the distribution of public keys by the parties themselves or by a third party, such as a
Certification Authority (CA). The solid-line arrows represent the distribution of nonces or
cryptographically protected values that occur during the key-agreement scheme. Note that the
flow diagrams in this Recommendation omit explicit mention of various validation checks that
are required. The flow diagrams and descriptions in this Recommendation assume a successful
completion of the key-agreement process.
For each scheme, there are conditions that must be satisfied to enable proper use of that scheme.
These conditions are listed as assumptions. Failure to meet all such conditions could yield
79
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 agents trusted to act on
their behalf (including application developers, system installers, and system administrators) are
responsible for ensuring that all assumptions are satisfied at the time that a key-establishment
transaction takes place.
80
8.2.1 KAS1 Assumptions
1. Party V has been designated as the owner of a key-establishment key pair that was
generated as specified in Section 6.3. Party V has assurance of possession of the correct
value for its private key as specified in Section 6.4.1.5.
2. Party U and party V have agreed upon an approved key-derivation method (see Section
5.5), as well as an approved algorithm to be used with that method (e.g., a specific hash
function) and other associated parameters related to the cryptographic elements to be
used.
3. If key confirmation is used, party U and party V have agreed upon an approved MAC
algorithm and associated parameters, including the lengths of MacKey and MacTag (see
Section 5.2).
4. When an identifier is used to label either party during the key-agreement process, both
parties are aware of the particular identifier employed for that purpose. In particular,
when an identifier is used to label party V during the key-agreement process, that
identifiers association with party Vs public key is trusted by party U. 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.
5. Party U has obtained assurance of the validity of party Vs public key, as specified in
Section 6.4.2.
The following is an assumption for using any keying material derived during a KAS1 key-
agreement scheme for purposes beyond those of the scheme itself.
Party U has obtained (or will obtain) assurance that party V is (or was) in possession of
the private key corresponding to the public key used during the key-agreement
transaction, as specified in Section 6.4.2.3.
This assumption recognizes the possibility that assurance of private-key possession may be
provided/obtained by means of key confirmation performed as part of a particular KAS1
transaction.
8.2.2 KAS1-basic
KAS1-basic is the basic key-agreement scheme in the KAS1 family. In this scheme, party V
does not contribute to the formation of the shared secret; instead, a nonce is used as a party V-
selected contribution to the key-derivation method, ensuring that both parties influence the
derived keying material.
Let (PubKeyV, PrivKeyV) be party Vs key-establishment key pair. Let KBits be the intended
length in bits of the keying material to be established. The parties shall perform the following or
an equivalent sequence of steps, as illustrated in Figure 8.
Party U shall execute the following key-agreement transformation in order to a) establish a
shared secret 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:
81
1. Use the RSASVE.GENERATE operation in Section 7.2.1.2 to generate a secret value Z
and a corresponding ciphertext C using party Vs public key-establishment key
PubKeyV. Note that the secret value Z will become a shared secret when recovered by
Party V.
2. Send the ciphertext C to party V.
3. Obtain party Vs nonce NV from party V. If NV is not available, return an error
indicator without performing the remaining actions.
4. Construct the other information (e.g., OtherInfo) for key derivation (see Section 5.5)
using the nonce NV and the identifiers IDU and IDV, if available.
5. Use the agreed-upon key-derivation method (see Section 5.5) to derive secret keying
material with the specified length from the shared secret value Z and other input. If
the key-derivation method outputs an error indicator, return an error indicator without
performing the remaining actions.
6. Output the DerivedKeyingMaterial.
Any local copies of Z, OtherInfo, DerivedKeyingMaterial and any intermediate values used
during the execution of party Us actions shall be destroyed prior to or during the termination of
the actions in steps 3, 4, and 6.
Party V shall execute the following key-agreement transformation in order to a) establish a
shared secret Z with party U, and b) derive secret keying material from Z.
Actions: Party V obtains the shared secret and derives secret keying material as follows:
1. Receive a ciphertext C from party U.
2. Use the RSASVE.RECOVER operation in Section 7.2.1.3 to recover the secret value Z
from the ciphertext C using the private key-establishment key PrivKeyV; hereafter, Z
is considered to be a shared secret. If the call to RSASVE.RECOVER outputs an error
indicator, return an error indicator without performing the remaining actions.
3. Obtain a nonce NV (see Section 5.4), and send NV to party U.
4. Construct the other information OtherInfo for key derivation (see Section 5.5) using
the nonce NV and the identifiers IDU and IDV, if available.
5. Use the agreed-upon key-derivation method to derive secret keying material with the
specified length from the shared secret value Z and other input. If the key-derivation
method outputs an error indicator, return an error indicator without performing the
remaining actions.
6. Output the DerivedKeyingMaterial.
Any local copies of Z, PrivKeyV, OtherInfo, DerivedKeyingMaterial and any intermediate values
used during the execution of party Vs actions shall be destroyed prior to or during the
termination of the actions in steps 2, 5 and 6.
Party U Party V
82
(PubKeyV, PrivKeyV)
C
(Z, C) = Z=
RSASVE.GENERATE(PubKeyV) RSASVE.RECOVER(PrivKeyV, C)
Compute NV
Compute
DerivedKeyingMaterial
DerivedKeyingMaterial
and destroy Z
and destroy Z
83
8.2.3.2 KAS1-Party_V-confirmation
Figure 9 depicts a typical flow for a KAS1 scheme with unilateral key confirmation from party V
to party U. In this scheme, party V and party U assume the roles of key-confirmation provider
and recipient, respectively.
To provide (and receive) key confirmation (as described in Section 5.6.1.1), both parties set
EphemDataV = NV, and EphemDataU = C:
Party V provides MacTagV to party U (as specified in Section 5.6.1.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 || NV || C{ || TextV}.
Party U uses the identical format and values to compute MacTagV, and then verifies that the
newly computed MacTagV matches the MacTagV value provided by party V.
The MacKey used during key confirmation shall be destroyed by party V immediately after the
computation of MacTagV, and by party U immediately after the verification of the received
MacTagV or a (final) determination that the received MacTagV is in error.
Party U Party V
(PubKeyV, PrivKeyV)
PubKey
Obtain party Vs public key-
establishment key
C Z=
(Z, C) =
RSASVE.RECOVER(PrivKeyV,
RSASVE.GENERATE(PubKeyV)
C)
Compute NV Compute
DerivedKeyingMaterial = DerivedKeyingMaterial =
MacKey || KeyData MacKey || KeyData
and destroy Z and destroy Z
84
8.3 KAS2 Key Agreement
In this family of key-agreement schemes, key-establishment key pairs are used by both party U
and party V.
The schemes in this family have the following general form:
1. Party U generates a secret value (which will become a component of the shared secret)
and a corresponding ciphertext using the RSASVE.GENERATE operation and party Vs
public key-establishment key, and sends the ciphertext to party V.
2. Party V recovers party Us secret component from the ciphertext received from party U
using the RSASVE.RECOVER operation and its private key-establishment key.
3. Party V generates a secret value (which will become a second component of the shared
secret) and the corresponding ciphertext using the RSASVE.GENERATE operation and
party Us public key-establishment key, and sends the ciphertext to party U.
4. Party U recovers party Vs secret component from the ciphertext received from party V
using the RSASVE.RECOVER operation and its private key-establishment key.
5. Both parties concatenate the two secret components to form the shared secret, and then
derive keying material from the shared secret and other information using a key-
derivation method. The length of the keying material that can be agreed on is limited only
by the length that can be output by the key-derivation method.
6. Party U and/or party V may additionally provide key confirmation. If key confirmation is
incorporated, then the derived keying material is parsed into two parts, MacKey and
KeyData. MacKey is then used to compute a MAC tag of MacTagLen bytes on MacData
(see Sections 5.2.1, 5.2.2, 5.6.1 and 5.6.3). MacTag is sent from the KC provider to the
KC recipient. If the MAC tag computed by the provider matches the MAC tag computed
by the recipient, then the successful establishment of keying material is confirmed by the
recipient.
The following schemes are defined:
1. KAS2-basic, the basic scheme without key confirmation (see Section 8.3.2).
2. KAS2-Party_V-confirmation, a variant of KAS2-basic with unilateral key
confirmation from party V to party U (see Section 8.3.3.2).
3. KAS2-Party_U-confirmation, a variant of KAS2-basic with unilateral key
confirmation from party U to party V (see Section 8.3.3.3).
4. KAS2-bilateral-confirmation, a variant of KAS2-basic with bilateral key
confirmation between party U and party V (see Section 8.3.3.4).
For the security properties of the KAS2 key-agreement schemes, see Section 10.2.
85
party has obtained assurance of its possession of the correct value for its own private key
as specified in Section 6.4.1.5.
2. The parties have agreed upon an approved key-derivation method (see Section 5.6), as
well as an approved algorithm to be used with that method (e.g., a hash function) and
other associated parameters to be used for key derivation.
3. If key confirmation is used, party U and party V have agreed upon an approved MAC
algorithm and associated parameters, including the lengths of MacKey and MacTag (see
Section 5.2). The parties must also agree on whether one party or both parties will send
MacTag, and in what order.
4. When an identifier is used to label a party during the key-agreement process, that
identifier has a trusted association to that partys public key. (In other words, whenever
both the identifier and public key of one participant are employed in the key-agreement
process, they are associated in a manner that is trusted by the other participant.) 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.
5. Each party has obtained assurance of the validity of the public keys that are used during
the transaction, as specified in Section 6.4.2.3.
The following is an assumption for using any keying material derived during a KAS2 key-
agreement scheme for purposes beyond those of the scheme itself.
Each party has obtained (or will obtain) assurance that the other party is (or was) in
possession of the private key corresponding to their public key that was used during the
key-agreement transaction, as specified in Section 6.4.2.3.
This assumption recognizes the possibility that assurance of private-key possession may be
provided/obtained by means of key confirmation performed as part of a particular KAS2
transaction.
8.3.2 KAS2-basic
Figure 10 depicts the typical flow for the KAS2-basic scheme. The parties exchange secret
values that are concatenated together to form the mutually determined shared secret to be input
to the key-derivation method.
Party U shall execute the following key-agreement transformation in order to a) establish a
mutually determined shared secret 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. Use the RSASVE.GENERATE operation in Section 7.2.1.2 to generate a secret value
ZU and a corresponding ciphertext CU using party Vs public key-establishment key
PubKeyV.
2. Send the ciphertext CU to party V.
3. Receive a ciphertext CV from party V. If CV is not available, return an error indicator
without performing the remaining actions.
4. Use the RSASVE.RECOVER operation in Section 7.2.1.3 to recover ZV from the
ciphertext CV using the private key-establishment key PrivKeyU. If the call to
86
RSASVE.RECOVER outputs an error indicator, return an error indicator without
performing the remaining actions.
5. Construct the mutually determined shared secret Z from ZU and ZV
Z = ZU || ZV.
6. Construct the other information (e.g., OtherInfo) for key derivation (see Section 5.5)
using the identifiers IDU and IDV, if available.
7 Use the agreed-upon key-derivation method (see Section 5.6) to derive secret keying
material with the specified length from the shared secret Z and other input. If the key-
derivation method outputs an error indicator, return an error indicator without
performing the remaining actions.
8. Output the DerivedKeyingMaterial.
Any local copies of Z, ZU, ZV, PrivKeyU, OtherInfo, DerivedKeyingMaterial and any intermediate
values used during the execution of party Us actions shall be destroyed prior to or during the
termination of the actions in steps 3, 4, 7 and 8.
Party V shall execute the following key-agreement transformation in order to a) establish a
mutually determined shared secret Z with party U, and b) derive secret keying material from Z.
Actions: Party V generates a shared secret and derives secret keying material as follows:
1. Receive a ciphertext CU from party U.
2. Use the RSASVE.RECOVER operation in Section 7.2.1.3 to recover ZU from the
ciphertext CU using the private key-establishment key PrivKeyU. If the call to
RSASVE.RECOVER outputs an error indicator, return an error indicator without
performing the remaining actions.
3. Use the RSASVE.GENERATE operation in Section 7.2.1.2 to generate a secret value
ZV and a corresponding ciphertext CV using party Us public key-establishment key
PubKeyU.
4. Send the ciphertext CV to party U.
5. Construct the mutually determined shared secret Z from ZU and ZV
Z = ZU || ZV.
6. Construct the other information (e.g., OtherInfo) for key derivation (see Section 5.5)
using the identifiers IDU and IDV, if available.
7. Use the agreed-upon key-derivation method (see Section 5.5) to derive secret keying
material DerivedKeyingMaterial of length KBits from the shared secret Z and
OtherInfo. If the key-derivation method outputs an error indicator, return an error
indicator without performing the remaining actions.
8. Output the DerivedKeyingMaterial.
87
Any local copies of Z, ZU, ZV, PrivKeyV, OtherInfo, DerivedKeyingMaterial and any intermediate
values used during the execution of party Vs actions shall be destroyed prior to or during the
termination of the actions in steps 2, 7 and 8.
Party U Party V
ZU =
(ZU, CU) = CU
RSASVE.RECOVER(PrivKeyV,
RSASVE.GENERATE(PubKeyV)
CU)
ZV =
CV (ZV, CV) =
RSASVE.RECOVER(PrivKeyU,
RSASVE.GENERATE(PubKeyU)
CV)
Z = ZU || ZV Z = ZU || ZV
Compute Compute
DerivedKeyingMaterial DerivedKeyingMaterial
and destroy Z and destroy Z
88
b. MacTagLen: the length in bytes of MacTag.
For KAS2 key confirmation, the length of the keying material shall be at least 14 bytes for a
256-byte (i.e., 2048-bit) modulus, and at least 16 bytes for a 384-byte (i.e., 3072-bit) modulus.
The keying material is usually longer so that other keying material is available for subsequent
operations. MacKey shall be the first MacKeyLen bytes of the keying material and shall be used
only for the key-confirmation operation.
8.3.3.2 KAS2-Party_V-confirmation
Figure 11 depicts a typical flow for a KAS2 scheme with unilateral key confirmation from party
V to party U. In this scheme, party V and party U assume the roles of the key-confirmation
provider and recipient, respectively.
To perform key confirmation (as described in Section 5.6.1.1), both parties set EphemDataV =
CV, and EphemDataU = CU.
Party V provides MacTagV to party U (as specified in Section 5.6.1.1, with P = V and R = U),
where MacTagV is computed (as specified in Section 5.2.1) on
MacDataV = KC_1_V || IDV || IDU || CV || CU{ || TextV}.
Party U (the KC recipient) uses the identical format and values to compute MacTagV and then
verifies that the newly computed MacTagV equals MacTagV as provided by party V.
The MAC key used during key confirmation (i.e., MacKey) shall be destroyed by party V
immediately after the computation of MacTagV, and by party U immediately after the
verification of the received MacTagV or a (final) determination that the received MacTagV is in
error.
Party U Party V
(ZU, CU) = CU ZU =
RSASVE.Generate(PubKeyV) RSASVE.Recover(PrivKeyV, CU)
ZV =
CV (ZV, CV) =
RSASVE.RECOVER(PrivKeyU,
RSASVE.GENERATE(PubKeyU)
CV)
Z = ZU || ZV Z = ZU || ZV
89
Compute Compute
DerivedKeyingMaterial = DerivedKeyingMaterial =
MacKey || KeyData MacKey || KeyData
and destroy Z and destroy Z
8.3.3.3 KAS2-Party_U-confirmation
Figure 12 depicts a typical flow for a KAS2 scheme with unilateral key confirmation from party
U to party V. In this scheme, party U and party V assume the roles of key-confirmation provider
and recipient, respectively.
To provide (and receive) key confirmation (as described in Section 5.6.1.1), both parties set
EphemDataV = CV, and EphemDataU = CU.
Party U provides MacTagU to party V (as specified in Section 5.6.1.1, with P = U and R = V),
where MacTagU is computed (as specified in Section 5.2.1) on
MacDataU = KC_1_U || IDU || IDV || CU || CV{ || TextU}.
Party V (the KC recipient) uses the identical format and values to compute MacTagU and then
verifies that the newly computed MacTagU matches the MacTagU value provided by party U.
The MAC key used during key confirmation shall be destroyed by party U immediately after the
computation of MacTagU, and by party V immediately after the verification of the received
MacTagU or a (final) determination that the received MacTagU is in error.
90
Party U Party V
ZU =
(ZU, CU) = CU
RSASVE.RECOVER(PrivKeyV,
RSASVE.GENERATE(PubKeyV)
CU)
ZV =
CV (ZV, CV) =
RSASVE.RECOVER(PrivKeyU,
RSASVE.GENERATE(PubKeyU)
CV)
Z = ZU ZV Z = ZU ZV
Compute Compute
DerivedKeyingMaterial = DerivedKeyingMaterial =
MacKey || KeyData MacKey || KeyData
and destroy Z and destroy Z
8.3.3.4 KAS2-bilateral-confirmation
Figure 13 depicts a typical flow for a KAS2 scheme with bilateral key confirmation. In this
scheme, party U and party V assume the roles of both the KC provider and recipient in order to
obtain bilateral key confirmation.
To provide bilateral key confirmation (as described in Section 5.6.1.2), party U and party V
exchange and verify MacTags that have been computed (as specified in Section 5.9.1.1) using
EphemDataU = CU, and EphemDataV = CV.
Party V provides MacTagV to party U (as specified in Section 5.6.1.1, with P = V and R = U);
MacTagV is computed by party V (and verified by party U) on
MacDataV = KC_2_V || IDV || IDU || CV || CU{ || TextV}.
91
Party U provides MacTagU to party V (as specified in Section 5.6.1.1, with P = U and R = V);
MacTagU is computed by party U (and verified by party V) on
MacDataU = KC_2_U || IDU || IDV || CU || CV{ || TextU}.
The MAC key used during key confirmation shall be destroyed by each party immediately
following its use to compute and verify the MAC tags used for key confirmation. Once party U
has computed MacTagU and has either verified the received MacTagV or made a (final)
determination that the received MacTagU is in error, party U shall immediately destroy its copy
of MacKey. Similarly, after party V has computed MacTagV and has either verified the received
MacTagU or made a (final) determination that the received MacTagU is in error, party V shall
immediately destroy its copy of MacKey.
Party U Party V
CU ZU =
(ZU, CU) =
RSASVE.RECOVER(PrivKeyV,
RSASVE.GENERATE(PubKeyV)
CU)
ZV = CV (ZV, CV) =
RSASVE.RECOVER(PrivKeyU,
RSASVE.GENERATE(PubKeyV)
CV)
Z = ZU ZV Z = ZU ZV
Compute Compute
DerivedKeyingMaterial = DerivedKeyingMaterial =
MacKey || KeyData MacKey || KeyData
and destroy Z and destroy Z
92
Certain messages may be sent in a different order (and/or combined with others), e.g., CV may be
sent before CU and/or MacTagV may be sent before MacTagU.
9 Key-Transport Schemes
In a key-transport scheme, two parties, party U (the sender) and party V (the receiver), establish
keying material selected initially by party U. The keying material may be cryptographically
bound to additional input (see Section 9.1).
In this Recommendation, two families of key-transport schemes are specified: KTS-OAEP and
KTS-KEM-KWS.
Key confirmation is included in some of these schemes to provide assurance to the sender that
the participants share the same keying material (see Section 5.6 for further details on key
confirmation).
In key-transport schemes that provide key confirmation (see Sections 9.2.4.2 and 9.3.4.2), the
transported keying material shall contain a MAC key as the first bits of the keying material such
that
TransportedKeyingMaterial = MacKey || KeyData.
MacKey will be used for the computation and verification of the MAC tag. KeyData is the
keying material to be used subsequent to the key-transport transaction. The MAC key shall be
generated anew for each instance of a key-establishment transaction using an approved random
bit generator that supports the security strength required for the key-establishment transaction.
The MAC key length (in bits) shall be equal to or greater than the security strength associated
with the modulus length (in bits) used in the key-establishment scheme (see SP 800-57-Part 1
[SP 800-57]). KeyData may be null, or may contain keying material to be used subsequent to the
key-transport transaction. MacKey shall be used during key confirmation and then immediately
destroyed.
In key-transport schemes that do not provide key confirmation (see Sections 9.2.4.1 and 9.3.4.1),
the TransportedKeyingMaterial = KeyData.
A general flow diagram is provided for each key-transport scheme. The dotted-line arrows
represent the distribution of public keys by the parties themselves or by a third party, such as a
Certification Authority (CA). The solid-line arrows represent the distribution of
cryptographically protected values that occur during the key-transport 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 and descriptions in this Recommendation
assume a successful completion of the key-transport process.
As in Section 8, there are conditions that must be satisfied for each key-transport scheme to
enable proper use of that scheme. These conditions are listed as assumptions. Failure to meet any
of 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 agents trusted to act on their behalf (including application developers, system installers,
and system administrators) are responsible for ensuring that all assumptions are satisfied at the
time that a key-establishment transaction takes place.
93
9.1 Additional Input
Additional input to the key-transport process may be employed to ensure that the transported
keying material is adequately bound to the context of the key-transport transaction. The use of
additional input, A, is explicitly supported by the key-transport schemes specified in Sections 9.2
and 9.3. Each party to a key-transport transaction shall know whether or not additional input is
employed in that transaction.
Context-specific information that may be appropriate for inclusion in the additional input:
Public information about parties U and V, such as names, e-mail addresses, and/or other
identifiers.
An identifier and/or other information associated with the RSA public key employed in
the key-transport transaction. One might, for example, include (a hash of) a certificate
that contains that RSA public key.
Other public and/or private information shared between parties U and V before or during
the transaction, such as nonces, counters, or pre-shared secret data. (The inclusion of
private information is limited to situations in which the additional input, A, is afforded
adequate confidentiality protection.)
An indication of the protocol or application employing the key-transport scheme.
Protocol-related information, such as a label or session identifier.
An indication of the key-transport scheme used during the transaction.
An indication of various parameter or primitive choices (e.g., hash functions, MAC
algorithms, MacTag lengths, etc.).
An indication of how the transported keying material should be parsed, including an
indication of which algorithm(s) will use the (parsed) keying material.
Both parties to the key-transport transaction shall know the format of the additional input, A, and
shall acquire A in time to use it as required by the scheme. The methods used for formatting and
distributing the additional input are application-defined. System users and/or agents trusted to act
on their behalf should determine that the information selected for inclusion in A and the methods
used for formatting and distributing A meet the security requirements of those users.
94
(the receivers) public key-establishment key to produce ciphertext, and sends the
ciphertext to party V.
2. Party V decrypts the ciphertext using its private key-establishment key and the RSA-
OAEP.DECRYPT operation to recover the transported keying material.
3. If key confirmation is incorporated, then the transported keying material is parsed into
two parts, a transaction-specific (random) value for MacKey, followed by KeyData. The
Mackey portion of the keying material and an approved MAC algorithm are used by
each party to compute a MAC tag (of an appropriate, agreed-upon length) on what should
be the same MacData (see Sections 5.6 and 9.2.4.2). The MAC tag computed by party V
(the key-confirmation provider) is sent to party U (the key-confirmation recipient). If the
value of the MAC tag sent by party V matches the MAC tag value computed by party U,
then party U obtains a confirmation of the success of the key-transport transaction.
The common components of the schemes in the KTS-OAEP family are listed in Section 9.2.2.
The following schemes are then defined:
1. KTS-OAEP-basic, the basic scheme without key confirmation (see Section 9.2.3).
For the security attributes of the KTS-OAEP family, see Section 10.3.
95
7. Prior to or during the key-transport process, party U has obtained (or will obtain)
assurance that party V is (or was) in possession of the (correct) private key corresponding
to the public key-establishment key used during the transaction, as specified in Section
6.4.2.
8. Prior to or during the key-transport process, the keying material to be transported has
been/is determined and has a format as specified at the beginning of Section 9.
9.2.3 KTS-OAEP-basic
KTS-OAEP-basic is the basic key-transport scheme in the KTS-OAEP family without key
confirmation.
Let (PubKeyV, PrivKeyV) be party Vs (the receivers) key-establishment key pair. Let K be the
keying material to be transported from party U (the sender) to party V; note that the length of K
is restricted by the length of the RSA modulus and the length of the hash-function used during
the RSA-OAEP process (see Section 7.2.2.3). The parties shall perform the following or an
equivalent sequence of steps, which are also illustrated in Figure 14.
Party U shall execute the following steps in order to transport keying material to party V.
Party U Actions:
1. Encrypt the keying material K using party Vs public key-establishment key PubKeyV
and the additional input A, to produce a ciphertext C (see Section 7.2.2.3):
C = RSA-OAEP.ENCRYPT(PubKeyV, K, A).
2. If an error indication has been returned, then return an error indication without
performing the remaining actions.
Any local copies of K, A, and any intermediate values used during the execution of party Us
actions shall be destroyed prior to or during step 2.
Party V shall execute the following steps when receiving keys transported from party U.
Party V Actions:
2. Decrypt the ciphertext C using the private key-establishment key PrivKeyV and the
additional input A, to recover the transported keying material K (see Section 7.2.2.4):
96
K = RSA-OAEP.DECRYPT(PrivKeyV, C, A).
3. Output K.
Any local copies of K, PrivKeyV, A, and any intermediate values used during the execution of
party Vs actions shall be destroyed prior to or during step 3.
Party U Party V
C = RSA-OAEP. C K = RSA-OAEP.
ENCRYPT(PubKeyV, K, A) DECRYPT(PrivKeyV, C, A)
For KAS2 key confirmation, the length of the keying material shall be at least 14 bytes for a
256-byte (i.e., 2048-bit) modulus, and 16 bytes for a 384-byte (i.e., 3072-bit) modulus, and
usually longer so that keying material other than MacKey is available for subsequent operations.
MacKey shall be the first MacKeyLen bytes of the keying material and shall be used only for the
key-confirmation operation.
9.2.4.2 KTS-OAEP-Party_V-confirmation
KTS-OAEP-Party_V-confirmation is a variant of KTS-OAEP-basic with unilateral key
confirmation from party V to party U.
97
Figure 15 depicts a typical flow for the KTS-OAEP-Party_V-confirmation scheme. In this
scheme, party V and party U assume the roles of key-confirmation provider and recipient,
respectively.
To provide (and receive) key confirmation (as described in Section 5.6.1.1), both parties form
MacData with EphemDataV = Null, and EphemDataU = C:
Party V provides MacTagV to party U (as specified in Section 5.6.1.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 || C{ || TextV}.
Party U uses the identical format and values to compute MacTagV, and then verifies that the
newly computed MacTagV matches the MacTagV value provided by party V.
The MAC tag used during key confirmation shall be destroyed by party V immediately after the
computation of MacTagV, and by party U immediately after the verification of the received
MacTagV or a (final) determination that the received MacTagV is in error.
Party U Party V
C = RSA-OAEP. C K = RSA-OAEP.
ENCRYPT(PubKeyV, K, A) DECRYPT(PrivKeyV, C, A)
MacKey || KeyData = K
MacTagV =? MacTagV =
MacTagV
TMacTagBits[MAC(MacKey, TMacTagBits[MAC(MacKey,
MacDataV)] MacDataV)]
98
1. Using the RSA-KEM-KWS.ENCRYPT operation, party U (the sender) first generates a
secret byte string Z and a corresponding ciphertext component by employing the
RSASVE.GENERATE operation and the public key-establishment key of party V (the
receiver). The byte string Z (along with OtherInfo or its equivalent) is then used as input
to the key-derivation method to derive a transaction-specific key-wrapping key (KWK) of
an appropriate, agreed-upon bit length kwkBits. The keying material to be transported is
wrapped using the KWK and the symmetric key-wrapping method to produce a second
ciphertext component. The two ciphertext components are sent to party V.
Common components of the schemes in the KTS-KEM-KWS family are listed in Section 9.3.2.
Two schemes are then defined:
1. KTS-KEM-KWS-basic, the basic scheme without key confirmation (see Section 9.3.3).
For the security attributes of the KTS-KEM-KWS family, see Section 10.4.
99
Section 9.3.3. The key-wrapping method protects the transported keying material at a
security strength that is equal to or greater than the target security strength of the
applicable key transport scheme (see Section 7.2.3). If the CCM mode is used during key
wrapping, the sender and receiver have agreed on the counter-generation function, the
formatting function, and the length of the MAC tag to be used during the key-wrapping
operation (see Section 7.2.3.2.1). If the KW or KWP mode is used for key wrapping, the
sender and receiver have agreed on the cipher function and the valid plaintext lengths to
be used during key wrapping.
4. If the CCM mode will be used for key wrapping, prior to or during the transport process,
the parties have either agreed upon the format and content of the additional input A (a
byte string to be cryptographically bound to the transported keying material in that the
cipher is a cryptographic function of both values), or agreed that A will be the empty
string (see Section 9.1 above). Note that for the KW and KWP modes, additional input is
not accommodated.
5. If key confirmation is used, the parties have agreed upon an approved MAC algorithm
and associated parameters (see Section 5.2).
6. When an identifier is used to label either party during the key-transport process, both
parties are aware of the particular identifier employed for that purpose. In particular,
when an identifier is used to label party V during the key-transport process, that
identifiers association to party Vs public key is trusted by party U. When an identifier is
used to label party U during the key-transport process, it has been selected/assigned in
accordance with the requirements of the protocol relying upon the use of the key-
transport scheme.
7. Party U has obtained assurance of the validity of party Vs public key, as specified in
Section 6.4.2.
8. Prior to or during the key-transport process, party U has obtained (or will obtain)
assurance that party V is (or was) in possession of the private key corresponding to the
public key-establishment key used during the transaction, as specified in Section 6.4.2.3.
9. Prior to or during the key-transport process, the keying material to be transported has
been (or will be) determined, with a format as specified at the beginning of Section 9.
9.3.3 KTS-KEM-KWS-basic
KTS-KEM-KWS-basic is the basic key-transport scheme in the KTS-KEM-KWS family
without key confirmation.
Let (PubKeyV, PrivKeyV) be party Vs key-establishment key pair. Let K be a local copy of the
keying material to be transported from party U to party V. The parties shall perform the
following or an equivalent sequence of steps, which are also illustrated in Figure 16.
100
Party U shall execute the following steps in order to transport keying material to party V.
Party U Actions:
1. Using party Vs public key-establishment key PubKeyV, the length kwkBits of the key to
be used for key-wrapping, and keying material K, generate a ciphertext C (see Section
7.2.3.3), which includes an encrypted Z value as C0 and the wrapped keying material as
C1. If the CCM mode is to be used for key wrapping, also generate a nonce (Nonce), and
include the nonce, the agreed-upon length of the MAC tag (TBits) and the additional
input A as input when invoking the RSA-KEM-KWS.ENCRYPT routine, i.e.:
C = RSA-KEM-KWS.ENCRYPT(PubKeyV, kwkBits, K, {, Nonce, TBits, A}).
2. If an error indication is returned, return an error indication without performing the
remaining actions.
3. Send the ciphertext C to party V, and, if the CCM mode was used for key wrapping, also
send Nonce.
Any local copies of K and any intermediate values used during the execution of party Us actions
shall be destroyed prior to or during steps 2 and 3.
Party V shall execute the following steps when receiving keys transported from party V.
Party V Actions:
1. Receive the transported keying material C, and if the CCM mode will be used for key
unwrapping, also receive Nonce.
2. Using the private key-establishment key PrivKeyV, the ciphertext C, and the length
kwkBits of the key-wrapping key, recover the keying material K (see Section 7.2.3.4). If
the CCM mode is to be used for key unwrapping, also include the received Nonce, the
agreed-upon length of the MAC tag (TBits) and the additional input A as input when
invoking the RSA-KEM-KWS.DECRYPT routine, i.e.:
K = RSA-KEM-KWS.DECRYPT(PrivKeyV, C, kwkBits {, Nonce, TBits, A}).
3. If the decryption operation outputs an error indicator, return an error indication without
performing the remaining actions.
4. Output K.
Any local copies of K, PrivKeyV, and any intermediate values used during the execution of party
Vs actions shall be destroyed prior to or during steps 3 and 4.
Party U Party V
101
Obtain party Vs public key- PubKeyV
establishment key
For KTS-KEM-KWS key confirmation, the length of the keying material shall be at least 14
bytes when nLen is 128 bytes and 16 bytes when nLen is 384 bytes, and usually longer so that
keying material other than MacKey is available for subsequent operations. MacKey shall be the
first MacKeyLen bytes of the keying material and shall be used only for key confirmation.
9.3.4.2 KTS-KEM-KWS-Party_V-confirmation
KTS-KEM-KWS-Party_V-confirmation is a variant of KTS-KEM-KWS-basic with
unilateral key confirmation from party V to party U.
Figure 17 depicts a typical flow for the KTS-KEM-KWS-Party_V-confirmation scheme. In
this scheme, party V and party U assume the roles of the key-confirmation provider and
recipient, respectively.
To provide (and receive) key confirmation (as described in Section 5.6.1.1), both parties set
EphemDataV = Null, and EphemDataU = C.
Party V provides MacTagV to party U (as specified in Section 5.6.1.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 || C{ || TextV}.
Party U uses the identical format and values to compute MacTagV and then verifies that the
newly computed MacTagV matches the MacTagV value provided by party V.
102
The MacKey value used during key confirmation shall be destroyed by party V immediately
after the computation of MacTagV, and by party U immediately after the verification of the
received MacTagV or a (final) determination that the received MacTagV is in error.
Party U Party V
C = RSA-KEM-KWS. K = RSA-KEM.KWS.
C {, Nonce}
ENCRYPT(PubKeyV, K {, Nonce, DECRYPT(PrivKeyV, C {,
TBits, A}) Nonce, TBits, A})
MacKey || KeyData = K
MacTagV =? MacTagV =
MacTagV
TMacTagBits[MAC(MacKey, TMacTagBits[MAC(MacKey,
MacDataV)] MacDataV)]
103
Note 1: In order to provide concise descriptions of security properties possessed by the various
schemes, it is necessary to make some assumptions concerning the format and type of data that is
used as input during key derivation. The following assumptions are made solely for the purposes
of Sections 10.1 through 10.4; they are not intended to preclude the options specified elsewhere
in this Recommendation.
1. When discussing the security properties of schemes, it is assumed that the OtherInfo
input to a (single-step) key-derivation function employed during a particular key-
agreement transaction uses either the concatenation format or the ASN.1 format (see
Section 5.5.1.2). It is also assumed that OtherInfo includes sufficiently specific identifiers
for the participants in the transaction, an identifier for the key-establishment scheme
being used during the transaction, and additional input (e.g., a nonce, 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.5.1.2 and Appendix B of [SP 800-56A] for further discussion concerning context-
specific information that may be appropriate for inclusion in OtherInfo).
2. In general, OtherInfo may include additional secret information (already shared between
parties U and V), but that is not assumed to be the case in the analysis of the security
properties that follows.
3. In cases where an approved extraction-then-expansion key-derivation procedure is
employed (see Section 5.5.2), it is assumed that the equivalent of this OtherInfo is used as
the Context input during the key-expansion step, as specified in [SP 800-56C].
4. Finally, it is assumed that all required nonces employed during a transaction are random
nonces that contain a component consisting of a random bit string formed in accordance
with the recommendations of Section 5.4.
Note 2: Different schemes may possess different security properties. 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 each exchange 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-establishment scheme is usually a component
of a larger protocol that may offer security-related assurances beyond those that can be provided
by the key-establishment scheme alone. For example, the protocol may include specific features
that limit opportunities for accidental or intentional misuse of the key-establishment component
of the protocol. Protocols, per se, are not specified in this Recommendation.
104
Each KAS1 scheme requires Alice to employ the RSASVE.GENERATE operation to select a
(random) secret value Z and encrypt it as ciphertext C using Bobs RSA public key. Unless
Bobs corresponding private key has been compromised, Alice has assurance that no unintended
entity (i.e., no one but Bob) could employ the RSASVE.RECOVER operation to obtain Z from C.
Absent the compromise of Bobs RSA private key and/or Z, Alice may attain a certain level of
confidence that she has correctly identified party V as Bob. Alices level of confidence is
dependent upon:
The specificity of the identifier that is associated with Bobs RSA public key,
The degree of trust in the association between that identifier and the public key,
The assurance of the validity of the public key, and
The availability of evidence that the keying material has been correctly derived by Bob
using Z (and the other information input to the agreed-upon key-derivation method), e.g.
through key confirmation with Bob as the provider.
In general, Bob has no assurance that party U is Alice, since Bob has no assurance concerning
the accuracy of any identifier that may be used to label party U (unless, for example, the protocol
using a key-agreement scheme from the KAS1 family also includes additional elements that
establish a trusted association between an identifier for Alice and the ciphertext, C, that she
contributes to the transaction while acting as party U).
The assurance of freshness of the derived keying material that can be obtained by a participant in
a KAS1 transaction is commensurate with the participants assurance that different input will be
supplied to the agreed-upon key-derivation method during each such transaction. Alice can
obtain assurance that fresh keying material will be derived based on her unilateral selection and
contribution of the random Z value. Bob can obtain similar assurance owing to his selection and
contribution of the nonce NV, which is also used as input to the agreed-upon key-derivation
method.
The KAS1-Party_V-confirmation scheme permits party V to provide evidence to party U that
keying material has been correctly derived. When the KAS1-Party_V-confirmation scheme is
employed during a key-agreement transaction, party V provides a key-confirmation MAC tag,
MacTagV, to party U as specified in Section 8.2.3.2. This allows Alice (who is acting as party U,
the key-confirmation recipient) to obtain assurance that party V has possession of the MacKey
derived from the shared secret Z (and nonce NV) and has used it with the appropriate MacDataV
to compute the received MacTagV. In the absence of a compromise of secret information (e.g.,
Bobs RSA private key and/or Z), Alice can also obtain assurance that the appropriate identifier
has been used to label party V, and that the participant acting as party V is indeed Bob, the
owner of the RSA public key associated with that identifier.
Specifically, by successfully comparing the received value of MacTagV with her own
computation, Alice (acting as party U, the key-confirmation recipient) may obtain assurance that
1. Party V has correctly recovered Z from C, and, therefore, possesses the RSA private key
corresponding to Bobs RSA public key from which it may be inferred that party V is
Bob;
2. Both parties have correctly computed (at least) the same MacKey portion of the derived
keying material;
105
3. Both parties agree on the values (and representation) of IDV, IDU, NV, C, and any other
data included in MacDataV; and
4. Bob (acting as party V) has actively participated in the transaction.
Consequently, when the KAS1-Party_V-confirmation scheme is employed during a particular
key-agreement transaction (and neither Z nor Bobs RSA private key has been compromised),
Alice can obtain assurance of the active (and successful) participation in the transaction by Bob.
The acquisition of Bobs RSA private key by their adversary, Eve, may lead to the compromise
of shared secrets and derived keying material from past, current, and future legitimate
transactions (i.e., transactions that involve honest parties and are not actively influenced by an
adversary) that employ the compromised private key. For example, Eve may be able to
compromise a particular KAS1 transaction between Alice and Bob as long as she acquires the
ciphertext, C, contributed by Alice and the nonce, NV, contributed by Bob (as well as any other
data used as input during key derivation). In addition to compromising legitimate KAS1
transactions, once Eve has learned Bobs RSA private key, she may be able to impersonate Bob
while acting as party V in future KAS1 transactions (with Alice or any other party). Other
schemes and applications that rely on the compromised private key may also be adversely
affected. (See the appropriate subsection for details.)
Even without knowledge of Bobs private key, if Eve learns the value of Z that has been (or will
be) used in a particular KAS1 transaction between Alice and Bob, then she may be able to derive
the keying material resulting from that transaction as easily as Alice and Bob (as long as Eve
also acquires the value of NV and any other data used as input during key derivation).
Alternatively, armed with knowledge of the Z value that has been (or will be) selected by Alice,
Eve might be able to insert herself into the transaction (in the role of party V) while
masquerading as Bob.
106
Absent the compromise of Bobs RSA private key and/or ZU, Alice may attain a certain level of
confidence that she has correctly identified party V as Bob. Alices level of confidence is
commensurate with:
The specificity of the identifier that is associated with Bobs RSA public key,
The degree of trust in the association between that identifier and Bobs public key,
The assurance of validity of the public key, and
The availability of evidence that the keying material has been correctly derived by Bob
using Z = ZU || ZV (and the other information input to the agreed-upon key-derivation
method), e.g. through key-confirmation with Bob as the provider.
Similarly, absent the compromise of Alices private key and/or ZV, Bob may attain a certain level
of confidence that he has correctly identified party U as Alice. Bobs level of confidence is
commensurate with:
The specificity of the identifier that is associated with Alices RSA public key,
The degree of trust in the association between that identifier and Alices public key,
The assurance of validity of the public key, and
The availability of evidence that the keying material has been correctly derived by Alice
using Z = ZU || ZV (and the other information input to the agreed-upon key-derivation
method), e.g. through key-confirmation with Alice as the provider.
The assurance of freshness of the derived keying material that can be obtained by a participant in
a KAS2 transaction is commensurate with the participants assurance that different input will be
supplied to the agreed-upon key-derivation method during each such transaction. Alice can
obtain assurance that fresh keying material will be derived, based on her selection and
contribution of the random ZU component of Z. Bob can obtain similar assurance owing to his
selection and contribution of the random ZV component of Z.
Evidence that keying material has been correctly derived may be provided by using one of the
three schemes from the KAS2 family that incorporates key confirmation. The KAS2-Party_V-
confirmation scheme permits party V (Bob) to provide evidence of correct key derivation to
party U (Alice); the KAS2-Party_U-confirmation scheme permits party U (Alice) to provide
evidence of correct key derivation to party V (Bob); the KAS2-bilateral-confirmation scheme
permits each party to provide evidence of correct key derivation to the other party.
When the KAS2-Party_V-confirmation scheme or the KAS2-bilateral-confirmation scheme is
employed during a key-agreement transaction, party V provides a key-confirmation MAC tag,
MacTagV, to party U as specified in Section 8.3.3.2 or Section 8.3.3.4, respectively. This allows
Alice (who is the recipient of MacTagV) to obtain assurance that party V has possession of the
MacKey derived from the shared secret Z and has used it with the appropriate MacDataV to
compute the received MacTagV. In the absence of a compromise of secret information (e.g.,
Bobs RSA private key and/or ZU), Alice can also obtain assurance that the appropriate identifier
has been used to label party V, and that the participant acting as party V is indeed Bob, the
owner of the RSA public key associated with that identifier.
Similarly, when the KAS2-Party_U-confirmation scheme or the KAS2-bilateral-confirmation
scheme is employed during a key-agreement transaction, party U provides a key-confirmation
MAC tag, MacTagU, to party V as specified in Section 8.3.3.3 or Section 8.3.3.4, respectively.
This allows Bob (who is the recipient of MacTagU) to obtain assurance that party U has
107
possession of the MacKey derived from the shared secret Z and has used it with the appropriate
MacDataU to compute the received MacTagU. In the absence of a compromise of secret
information (e.g., Alices RSA private key and/or ZV), Bob can also obtain assurance that the
appropriate identifier has been used to label party U, and that the participant acting as party U is
indeed Alice, the owner of the RSA public key associated with that identifier.
Specifically, by successfully comparing the value of a received MAC tag with his/her own
computation, a key-confirmation recipient in a KAS2 transaction (be it Alice or Bob) may obtain
the following assurances.
1. He/She has correctly decrypted the ciphertext that was produced by the other party and,
thus, that he/she possesses the RSA private key corresponding to the RSA public key that
was used by the other party to produce that ciphertext from which it may be inferred
that the other party had access to the RSA public key owned by the key-confirmation
recipient. For example, if Alice is a key-confirmation recipient, she may obtain assurance
that she has correctly decrypted the ciphertext CV using her RSA private key, and so may
also obtain assurance that her corresponding RSA public key was used by party V to
produce CV.
2. The ciphertext sent to the other party was correctly decrypted and, thus, the other party
possesses the RSA private key corresponding to the RSA public key that was used to
produce that ciphertext from which it may be inferred that the other party is the owner
of that RSA public key. For example, if Alice is a key-confirmation recipient, she can
obtain assurance that party V has correctly decrypted the ciphertext CU using the RSA
private key corresponding to Bobs RSA public key from which she may infer that
party V is Bob.
3. Both parties have correctly computed (at least) the same MacKey portion of the derived
keying material.
4. Both parties agree on the values (and representation) of IDV, IDU, CV, CU, and any other
data included as input to the MAC algorithm.
5. Assuming that there has been no compromise of either participants RSA private key
and/or either component of Z, a key-confirmation recipient in a KAS2 transaction can
obtain assurance of the active (and successful) participation in that transaction by the
owner of the RSA public key associated with the key-confirmation provider. For
example, if Alice is a key-confirmation recipient, she can obtain assurance that Bob has
actively and successfully participated in that KAS2 transaction.
The acquisition of a single RSA private key by their adversary, Eve, will not (by itself) lead to
the compromise of derived keying material from legitimate KAS2 transactions between Alice
and Bob that employ the compromised RSA key pair. (In this context, a legitimate transaction
is one in which Alice and Bob act honestly, and there is no active influence exerted by Eve.)
However, if Eve acquires an RSA private key, she may be able to impersonate that RSA key
pairs owner while participating in KAS2 transactions. (For example, If Eve acquires Alices
private key, she may be able to impersonate Alice acting as party U or as party V in KAS2
transactions with Bob or any other party). Other schemes and applications that rely on the
compromised private key may also be adversely affected. (See the appropriate subsection for
details.)
108
Similarly, the acquisition of one (but not both) of the secret Z components, ZU or ZV, would not
(by itself) compromise the keying material derived during a legitimate KAS2 transaction
between Alice and Bob in which the compromised value was used as one of the two components
of Z. However, armed with knowledge of only one Z component, Eve could attempt to launch an
active attack against the party that generated it. For example, if Eve learns the value of ZU that
has been (or will be) contributed by Alice, then Eve might be able to insert herself into the
transaction by masquerading as Bob (while acting as party V). Likewise, an adversary who
knows the value of ZV that has been (or will be) selected by Bob might be able to participate in
the transaction by masquerading as Alice (while acting as party U).
109
the next, which may help obfuscate the occurrence of a repeated transport of the same keying
material from Alice to Bob, should that ever be necessary.
The KTS-OAEP-Party_V-confirmation scheme permits party V to provide evidence to party U
that keying material has been correctly recovered from the ciphertext C. When the KTS-OAEP-
Party_V-confirmation scheme is employed during a key-transport transaction, party V provides a
key-confirmation MAC tag (MacTagV) to party U as specified in Section 9.2.4.2. This allows
Alice (who is acting as party U, the key-confirmation recipient) to obtain assurance that party V
has recovered the fresh MAC key (MacKey) that was included in the transported keying material
and that party V has used it with the appropriate MacDataV to compute the received MacTagV. In
the absence of a compromise of secret information (e.g., Bobs RSA private key and/or the MAC
key), Alice can also obtain assurance that the appropriate identifier has been used to label party
V, and that the participant acting as party V is indeed Bob, the owner of the RSA public key
associated with that identifier.
Specifically, by successfully comparing the received value of MacTagV with her own
computation, Alice (acting as party U, the key-confirmation recipient) may obtain assurance that
1. Party V has correctly recovered MacKey from C, and, therefore, possesses the RSA
private key corresponding to Bobs RSA public key from which it may be inferred that
party V is Bob;
2. Both parties agree on the values (and representation) of IDV, IDU, C, and any other data
included in MacDataV; and
3. Bob has actively participated in the transaction (as party V), assuming that neither the
transported MAC key nor Bobs RSA private key has been compromised. Alices level of
confidence is commensurate with her confidence in the freshness of the MAC key.
The acquisition of Bobs RSA private key by their adversary, Eve, may lead to the compromise
of keying material established during past, current, and future legitimate transactions (i.e.,
transactions that involve honest parties and are not actively influenced by an adversary) that
employ the compromised private key. For example, Eve may be able to compromise a particular
KTS-OAEP transaction between Alice and Bob, as long as she also acquires the ciphertext, C,
sent from Alice to Bob. In addition to compromising legitimate KTS-OAEP transactions, once
Eve has learned Bobs RSA private key, she may be able to impersonate Bob while acting as
party V in future KTS-OAEP transactions (with Alice or any other party). Other schemes and
applications that rely on the compromised private key may also be adversely affected. (See the
discussions of other schemes in this section.)
Even without knowledge of Bobs private key, if the KTS-OAEP-Party_V-confirmation scheme
is used during a particular key-transport transaction, and Eve learns the value of MacKey that
Alice will send to Bob, then it may be possible for Eve to mislead Alice about Bobs (active and
successful) participation. As long as Eve also acquires the value of C intended for Bob (and any
other data needed to form MacDataV), it may be possible for Eve to correctly compute MacTagV
and return it to Alice as if it had come from Bob (who may not even be aware that Alice has
initiated a transaction with him). Such circumstances could arise, for example, if (in violation of
this Recommendation) Alice were to use the same MAC key while attempting to transport
keying material to multiple parties (including both Bob and Eve).
110
10.4 Rationale for Choosing a KTS-KEM-KWS Key-Transport Scheme
In each of the key-transport schemes included in the KTS-KEM-KWS family, only Bob
(assumed to be acting as party V, the key-transport receiver) is required to own an RSA key pair
that is used in the transaction. Assume that the identifier used to label party V during the
transaction is one that is associated with Bobs RSA public key in a manner that is trusted by
Alice (who is acting as party U, the key-transport sender). This can provide Alice with some
level of assurance that she has correctly identified the party with whom she will be establishing
keying material if the key-transport transaction is successfully completed.
Each KTS-KEM-KWS scheme requires Alice (as part of the RSA-KEM-KWS.ENCRYPT
operation) to employ the RSASVE.GENERATE operation to select a (random) secret value Z and
encrypt it as ciphertext C0 using Bobs RSA public key. A key-wrapping key, KWK, is derived
from Z (and other information input to the agreed-upon key-derivation method) and then KWK is
used by Alice to wrap the selected keying material (and any additional input) as ciphertext C1,
using the agreed-upon symmetric key-wrapping method. The concatenation of C0 and C1 forms
the ciphertext C that Alice sends to party V.
Unless Bobs RSA private key has been compromised, Alice has assurance that no unintended
entity (i.e., no one but Bob) could employ the RSASVE.RECOVER operation to obtain Z from C0,
derive KWK, and then use that key to obtain the plaintext keying material from C1. Absent the
compromise of Bobs RSA private key, Z, and/or KWK (or some compromise of the plaintext
keying material itself perhaps prior to transport), Alice may attain a certain level of confidence
that she has correctly identified party V as Bob. Alices level of confidence is commensurate
with:
The specificity of the identifier that is associated with Bobs RSA public key,
The degree of trust in the association between that identifier and the public key,
The assurance of validity of the public key,
The perceived strength of the key-wrapping method, and
The availability of evidence that the transported keying material has been correctly
unwrapped by Bob, e.g. through key confirmation with Bob as the provider.
In general, Bob has no assurance that party U is Alice, since Bob has no assurance concerning
the accuracy of any identifier that may be used to label party U (unless, for example, the protocol
using a key-transport scheme from the KTS-KEM-KWS family also includes additional elements
that establish a trusted association between an identifier for Alice and the ciphertext, C, that she
sends to Bob while acting as party U).
Due to Alices unilateral selection of the keying material that is transported, only she can obtain
assurance of its freshness. (Her level of confidence concerning its freshness is dependent upon
the actual manner in which the keying material is generated by/for her.) Given that Bob simply
accepts the keying material that is transported to him by Alice, he has no assurance that it is
fresh.
The use of a transaction-specific (random) Z (and hence, a transaction-specific KWK) can
provide assurance to Alice that the values of both C0 and C1 will change from one KTS-KEM-
KWS transaction with Bob to the next, which may help obfuscate the occurrence of a repeated
transport of the same keying material from Alice to Bob, should that ever be necessary.
111
The KTS-KEM-KWS-Party_V-confirmation scheme permits party V to provide evidence to
party U that keying material has been correctly recovered from the ciphertext C. When the KTS-
KEM-KWS-Party_V-confirmation scheme is employed during a key-transport transaction, party
V provides a key-confirmation MAC tag (MacTagV) to party U as specified in Section 9.3.4.2.
This allows Alice (who is acting as party U, the key-confirmation recipient) to obtain assurance
that party V has recovered the fresh MAC key (MacKey) that was included in the transported
keying material and that party V has used it with the appropriate MacDataV to compute the
received MacTagV. In the absence of a compromise of secret information (e.g., Bobs RSA
private key, Z, KWK, and/or MacKey), Alice can also obtain assurance that the appropriate
identifier has been used to label party V, and that the participant acting as party V is indeed Bob,
the owner of the RSA public key associated with that identifier.
Specifically, by successfully comparing the received value of MacTagV with her own
computation, Alice (acting as party U, the key-confirmation recipient) may obtain assurance that
Party V has correctly recovered Z from C0, and, therefore, possesses the RSA private key
corresponding to Bobs RSA public key from which it may be inferred that party V is
Bob;
Bob has correctly derived the key-wrapping key, KWK, from Z and the other information
input to the key-derivation method from which it may be inferred that both parties
agree on the value(s) (and representation) of that other information;
Bob has successfully used KWK to recover MacKey from C1;
Both parties agree on the values (and representation) of IDV, IDU, C, and any other data
included in MacDataV; and
Bob has actively participated in the transaction (as party V), assuming that neither Bobs
RSA private key, Z, KWK, nor MacKey has been compromised. Alices level of
confidence is commensurate with her confidence in the freshness of the MAC key.
The acquisition of Bobs RSA private key by their adversary, Eve, may lead to the compromise
of keying material established during past, current, and future legitimate transactions (i.e.,
transactions that involve honest parties and are not actively influenced by an adversary) that
employ the compromised private key. For example, Eve may be able to compromise a particular
KTS-KEM-KWS transaction between Alice and Bob, given that she acquires the ciphertext (and
other data) sent from Alice to Bob. (Besides the ciphertext, Eve must acquire the other
information that was used along with Z to derive the key-wrapping key, and any other inputs
necessary for the key-unwrapping process). In addition to compromising legitimate KTS-KEM-
KWS transactions, once Eve has learned Bobs RSA private key, she may be able to impersonate
Bob while acting as party V in future KTS-KEM-KWS transactions (with Alice or any other
party). Other schemes and applications that rely on the compromised private key may also be
adversely affected. (See the appropriate subsection for details.)
Even without knowledge of Bobs private key, if Eve learns the value of Z that has been (or will
be) used in a particular KTS-KEM-KWS transaction between Alice and Bob, then Eve may be
able to derive the key-wrapping key, KWK, and unwrap the transported keying material as easily
as Bob (as long as she also acquires the ciphertext and other requisite data; a similar result would
follow from Eves acquisition of KWK by other means.) Alternatively, armed with knowledge of
112
the Z value that has been (or will be) selected by Alice (or armed with the corresponding value of
KWK), Eve might be able to insert herself into the transaction (in the role of party V) while
masquerading as Bob.
If the KTS-KEM-KWS-Party_V-confirmation scheme is used during a particular key-transport
transaction, and Eve learns the value of MacKey that Alice will send to Bob, then it may be
possible for Eve to mislead Alice about Bobs (active and successful) participation. As long as
Eve also acquires the value of C intended for Bob (and any other data needed to form
MacDataV), it may be possible for Eve to correctly compute MacTagV and return it to Alice as if
it had come from Bob (who may not even be aware that Alice has initiated a transaction with
him). Such circumstances could arise, for example, if (in violation of this Recommendation)
Alice were to use the same MAC key while attempting to transport keying material to multiple
parties (including both Bob and Eve).
11 Key Recovery
For some applications, the secret keying material used to protect data or to process protected 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 to reconstruct the secret keying material needs to be available (for example, the keys
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 the
following:
1. One or both keys of a key pair may be saved.
2. A key-wrapping key may be saved.
In addition, the following information that is used during key-establishment may need to be
saved:
3. The nonce(s),
4. The ciphertext,
5. Additional input, and
6. OtherInfo, or its equivalent.
General guidance on key recovery and the protections required for each type of key is provided
in the Recommendation for Key Management [SP 800-57].
12 Implementation Validation
When the NIST Cryptographic Algorithm Validation System (CAVS) has established a
validation program for this Recommendation, a vendor shall have its implementation tested and
validated by the Cryptographic Algorithm Validation Program (CAVP) and Cryptographic
Module Validation Program (CMVP) in order to claim conformance to this Recommendation.
Information on the CAVP and CMVP is available at http://csrc.nist.gov/cryptval/.
113
An implementation claiming conformance to this Recommendation shall include one or more of
the following capabilities:
Key-pair generation as specified in Section 6.3.
Explicit public-key validation as specified in Section 6.4.3.
A key-agreement scheme from Section 8, together with an approved random bit
generator and an approved key-derivation method from Section 5.5.
A key-transport scheme as specified in Section 9, together with an approved random bit
generator, an approved hash function, an approved symmetric key-wrapping method, as
specified in Section 7.2.3.2, and an approved key-derivation method from Section 5.5
for RSA-KEM-KWS based schemes.
An implementer shall also identify the appropriate specifics of the implementation, including:
The hash function to be used (see Section 5.1).
The MacKey length(s). The minimum length is 14 bytes for a 256-byte (i.e., 2048-bit)
modulus, and 16 bytes for a 384-byte (i.e., 3072-bit) modulus.
The length of the MAC tag (the minimum length is 64 bits, i.e., 8 bytes).
The key-establishment schemes available (see Sections 8 and 9).
The key-derivation method to be used if a key-agreement scheme is implemented,
including the format of OtherInfo or its equivalent (see Section 5.5).
The type of nonces to be generated (see Section 5.4).
How assurance of private-key possession and assurance of public-key validity are
expected to be achieved by both the owner and the recipient.
If a key-transport scheme is implemented, the key-wrapping method used and whether or
not a capability is available to handle additional input (see Section 7.2.3.2).
The RBG used, and its security strength (see Section 5.3).
114
Appendix A: References
A.1 Normative References
[FIPS 140] FIPS 140-2, Security Requirements for Cryptographic Modules, May 25, 2001.
FIPS 140-3 is currently under development.
[FIPS 140 IG] FIPS 140-2 Implementation Guidance; available at
http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf
[FIPS 180] FIPS 180-4 Secure Hash Standard, March 2012.
[FIPS 186] FIPS 186-4, Digital Signature Standard, July 2013.
[FIPS 197] FIPS 197, Advanced Encryption Standard, November 2001.
[FIPS 198] FIPS 198-1, The Keyed-Hash Message Authentication Code (HMAC), July 2008.
[FIPS 202] Draft FIPS 202, SHA-3 Standard: Permutation-Based Hash and Extendable-
Output Functions, August 2014.
[SP 800-38B] NIST SP 800-38B, Recommendation for Block Cipher Modes of Operation: The
CMAC Mode for Authentication, May 2005.
[SP 800-38C] NIST SP 800-38C, Recommendation for Block Cipher Modes of Operation: The
CCM Mode for Authentication and Confidentiality, May 2004.
[SP 800-38F] NIST SP 800-38F, Recommendation for Block Cipher Modes of Operation:
Methods for Key-wrapping, December 2012.
[SP 800-56A] NIST SP 800-56A, Recommendation for Pair-Wise Key-establishment Schemes
Using Discrete Logarithm Cryptography, Revision 2, May 2013.
[SP 800-56C] NIST SP 800-56C, Recommendation for Key Derivation through Extraction-then-
Expansion, November 2011.
[SP 800-57] NIST SP 800-57-Part 1, Recommendation for Key Management, Revision 3, July
2012.
[SP 800-67] NIST SP 800-67, Recommendation for the Triple Data Encryption Algorithm,
Revision 1, January 2012.
[SP 800-89] NIST SP 800-89, Recommendation for Obtaining Assurances for Digital
Signature Applications, November 2006.
[SP 800-90A] Recommendation for Random Number Generation Using Deterministic Random
Bit Generators, January 2012.
[SP 800-90B] DRAFT Recommendation for the Entropy Sources Used for Random Bit
Generation, August 2012.
[SP 800-90C] DRAFT Recommendation for Random Bit Generator (RBG) Constructions,
August 2012.
115
[SP 800-108] NIST SP 800-108, Recommendation for Key Derivation Using Pseudorandom
Functions, October 2009.
[SP 800-133] NIST SP 800-133, Recommendation for Cryptographic Key Generation,
November 2012.
[SP 800-135] NIST SP 800-135, Recommendation for Existing Application-Specific Key
Derivation Functions, Revision 1, December 2011.
[ANS X9.44] ANS X9.44 Public Key Cryptography for the Financial Services Industry: Key
Establishment Using Integer Factorization Cryptography, August 2007.
[ISO/IEC 8825] 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), December 2008.
[PKCS 1] Public Key Cryptography Series (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003.
116
Appendix B: Data Conversions (Normative)
B.1 Integer-to-Byte String (I2BS) Conversion
Input: A non-negative integer X and the intended length n of the byte string satisfying
28n > X.
Output: A byte string S of length n bytes.
1. Qn+1 = X.
2. For i = n to 1 by 1
2.1 Qi = (Qi+1)256.
2.2 Xi = Qi+1 - (Qi 256).
2.3 Si = the 8-bit binary representation of the non-negative integer Xi.
3. Let S1, S2,, Sn be the bytes of S from leftmost to rightmost.
4. Output S.
2. Let X = 0.
3. For i = 1 to SLen by 1
3.1 Let Xi be the non-negative integer whose 8-bit binary representation is Si.
4. Output X.
117
Appendix C: Prime-Factor Recovery (Normative)
The following algorithm recovers the prime factors of a modulus, given the public and private
exponents. The algorithm is based on Fact 1 in [Boneh 1999].
Function call: RecoverPrimeFactors(n, e, d)
Input:
1. n: modulus
2. e: public exponent
3. d: private exponent
Output:
1. (p, q): prime factors of modulus
b. Let y = gr mod n.
c. If y = 1 or y = n 1, then go to Step g.
d. For j = 1 to t 1 do:
i. Let x = y2 mod n.
ii. If x = 1, go to Step 5.
iii. If x = n 1, go to Step g.
iv. Let y = x.
e. Let x = y2 mod n.
f. If x = 1, go to Step 5.
118
g. Continue.
4. Output prime factors not found, and exit without further processing.
Any local copies of d, p, q , k, t, r, x, y, g and any intermediate values used during the execution
of the RecoverPrimeFactors function shall be destroyed prior to or during steps 4 and 6. Note
that this includes the values for p and q that are output in step 6.
Notes:
1. According to Fact 1 in [Boneh 1999], the probability that one of the values of y in an
iteration of Step 3 reveals the factors of the modulus is at least 1/2, so on average, at most
two iterations of that step will be required. If the prime factors are not revealed after 100
iterations, then the probability is overwhelming that the modulus is not the product of two
prime factors, or that the public and private exponents are not consistent with each other.
2. The algorithm bears some resemblance to the Miller-Rabin primality-testing algorithm
(see, e.g., FIPS 186).
3. The order of the recovered prime factors p and q may be the reverse of the order in which
the factors were generated originally.
119
Appendix D: Revisions (Informative)
In the 2014 revision, the following revisions were made:
Section 3.1 Added definitions of assumptions, binding, destroy, fresh, key-derivation
function, key-derivation method, key-wrapping key, MAC tag, and trusted association;
removed algorithm identifier, digital signature, initiator, responder.
Section 4 Used party U and party V to name the parties, rather than using the initiator
and responder as the parties. In Sections 8 and 9, the schemes have been accordingly
renamed: KAS1-responder-confirmation is now KAS1-Party_V-confirmation, KAS2-
responder-confirmation is now KAS2-Party_V-confirmation, KAS2-initiator-
confirmation is now KAS2-Party_U-confirmation, KTS-OAEP-receiver-confirmation is
not KTS-OAEP-Party_V-confirmation, and KTS-KEM-KWS-receiver-confirmation is
now KTS-KEM-KWS-Party_V-confirmation.
Section 4 Added requirements to destroy the local copies of secret and private values
and all intermediate calculations before terminating a routine normally or in response to
an error. Instructions to this effect have been inserted throughout the document.
The discussion about identifiers vs. identity and binding have been moved to Section 4.1.
Section 4.3 The phrase IFC-based has been removed throughout the document.
Section 5.4 More discussion has been added about the use of nonces, including new
requirements and recommendations.
Section 5.5 Key derivation has been divided into single-step key derivation methods
(Section 5.5.1), an extract-then-expand key derivation procedure (Section 5.5.2) and
application-specific key-derivation methods (Section 5.5.3).
Section 5.5.1.2 The use of OtherInfo (including identifiers) during the derivation of keys
is recommended, but no longer required (Section 5.5.1.2).
Moved the general introduction of key-confirmation to Section 5.9 The discussion now
incorporates the material from Section 6.6 of the previous version of the document.
Section 6.4 There is now a longer, and more thorough discussion of validity in Section
6.4. The concept of trusted associations has been introduced.
Section 6.4.1.1 Removed or TTP from the following: The key pair can be
revalidated at any time by the owner as follows.
Section 7.2.3.2 Moved discussion of symmetric key-wrapping methods from Section 5.7
to Section 7.2.3.2; much more information is now provided.
Section 10 The rationale for choosing each scheme type has been combined in this new
section, along with a discussion of their security properties.
The old Appendix A, Summary of Differences between this Recommendation and ANS
X9.44 (Informative), was removed.
120
The old Appendix E becomes Appendix D, and the changes introduced in this Revision
are listed here.
All figures are replaced to reflect the content, text, and terminology changes.
Security requirements have been updated; in particular, the 80-bit security strength is no
longer permitted in this Recommendation.
Changes to handle the destruction of local keys and intermediate values have been
introduced.
General changes have been made to make this Recommendation more similar to [SP 800
56A].
121