NIST SP 800-56B Rev. 2 日本語訳

Each participant that is required to do so by the key-agreement scheme or the relying application/protocol obtains an 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 entity’s public key for use in the key-agreement scheme obtains a public key that has a trusted association with the other party’s identifier, and obtains assurance of the validity of the public key. Approved methods for obtaining assurance of the validity of another entity’s 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 entity’s 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).

A Message Authentication Code (MAC) algorithm defines a family of one-way (MAC) functions that is parameterized by a symmetric key. The input to a MAC function includes a symmetric key, called \(\mathit{MacKey}\), and a binary data string, called \(\mathit{MacData}\). A MAC function is represented as \(\mathrm{MAC}(\mathit{MacKey}, \mathit{MacData}\ \{, \ldots\})\)¹². In this Recommendation, a MAC function is used in key confirmation (see Section 5.6) and may be used for key derivation (see Section 5.5 and SP 800-56C).

It must be computationally infeasible to determine the MAC of a (newly formed) \(\mathit{MacData}\) value without knowledge of the \(\mathit{MacKey}\) value (even if one has seen the MACs corresponding to other \(\mathit{MacData}\) values that were computed using that same \(\mathit{MacKey}\) value). Key confirmation requires the use of one of the following approved MAC algorithms: HMAC, AES-CMAC or KMAC. HMAC is specified in FIPS 198 and requires the use of an approved hash function. AES-CMAC is specified in SP 800-38B¹³ for the AES block cipher algorithm specified in FIPS 197. KMAC is specified in SP 800-185.¹⁴ When used for key confirmation, the key-confirmation provider is required to compute a "MAC tag" on received or derived data using the agreed-upon MAC function. A symmetric key derived from a shared secret (during a key-agreement transaction) or extracted from transported keying material (during a key-transport transaction) is used as \(\mathit{MacKey}\). The resulting MAC tag is sent to the key-confirmation recipient, who can obtain assurance (via MAC-tag verification) that the shared secret and derived keying material were correctly computed (in the case of key agreement) or that the transported keying material was successfully received (in the case of key transport). MAC-tag computation and verification are defined in Sections 5.2.1 and 5.2.2.

¹² Some MAC algorithms (e.g., KMAC) have additional parameters other than \(\mathit{MacKey}\) and \(\mathit{MacData}\).

5.2.1 \(\mathit{MacTag}\) Computation for Key Confirmation

1. An approved, agreed-upon MAC algorithm (see FIPS 198, SP 800-38B or SP 800-185) is used with \(\mathit{MacKey}\) to compute a MAC on the \(\mathit{MacData}\), where \(\mathit{MacKey}\) is a symmetric key, and \(\mathit{MacData}\) represents the data on which the MAC tag is computed. The minimum length of \(\mathit{MacKey}\) is specified in Section 5.6.3.

\(\mathit{MacKey}\) is obtained from the \(\mathit{DerivedKeyingMaterial}\) (when a key-agreement scheme employs key confirmation) or obtained from the \(\mathit{TransportedKeyingMaterial}\) (when a key-transport scheme employs key confirmation), as specified in Section 5.6.1.1. The resulting MAC consists of \(\mathit{MacOutputBits}\) bits, which is the full output length of the selected MAC algorithm.

2. The output of the MAC algorithm is input to a truncation function \(T_{\mathit{MacTagBits}}\) to obtain the most significant (i.e., leftmost) \(\mathit{MacTagBits}\) bits, where \(\mathit{MacTagBits}\) represents the intended length of \(\mathit{MacTag}\), which is required to be less than or equal to \(\mathit{MacOutputBits}\). (When \(\mathit{MacTagBits}\) equals \(\mathit{MacOutputBits}\), \(T_{\mathit{MacTagBits}}\) acts as the identity function.) The minimum value for \(\mathit{MacTagBits}\) is specified in Section 5.6.3.

Note: A routine implementing a Mac-tag computation for key confirmation shall destroy any local copies of \(\mathit{MacKey}\) and \(\mathit{MacData}\), any locally stored portions of \(\mathit{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 \(\mathit{MacTag}\) as the output.

5.2.2 \(\mathit{MacTag}\) Verification for Key Confirmation

To verify the MAC tag received during key confirmation, a new MAC tag, \(\mathit{MacTag}'\), is computed as specified in Section 5.2.1 using the values of \(\mathit{MacKey}\), \(\mathit{MacTagBits}\), and \(\mathit{MacData}\) possessed by the key-confirmation recipient. \(\mathit{MacTag}'\) is compared with the received MAC tag (i.e., \(\mathit{MacTag}\)). If their values are equal, then it may be inferred that the same \(\mathit{MacKey}\), \(\mathit{MacTagBits}\), and \(\mathit{MacData}\) values were used in the computation of \(\mathit{MacTag}\) and \(\mathit{MacTag}'\). That is, successful verification provides evidence that the key-confirmation provider has obtained the same MAC key as the key-confirmation recipient.

When an approved RBG is used to generate a secret value as part of a key-establishment scheme specified in this Recommendation (e.g., \(Z\) in a scheme from the KAS1 family), that RBG shall be instantiated to support a security strength that is equal to or greater than the security strength associated with the RSA modulus length as specified in SP 800-57, Part 1.

A nonce is a time-varying value that has a negligible chance of repeating (where the meaning of “negligible” may be application specific). This Recommendation requires party V to supply a nonce, \(N_V\), 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.

For the KAS1 schemes, the required nonce \(N_V\) should be a random nonce containing a random bit string output from an approved random bit generator (RBG), where both the security strength supported by the instantiation of the random bit generator and the bit length of the random bit string are greater than or equal to the targeted security strength of the key-agreement scheme in which the nonce is used; when feasible, the bit length of the random bit string should be (at least) twice the targeted security strength. For details concerning the security strength supported by an instantiation of a random bit generator, see SP 800-90.

An approved key-derivation method shall be used to derive keying material from the shared secret \(Z\) during the execution of a key-establishment scheme from the KAS1 or KAS2 family of schemes. The shared secret shall be used only by an approved key-derivation method and shall not be used for any other purpose.

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 treated as a critical security parameter (in a cryptographic module that is compliant with FIPS 140) and destroyed immediately following its use. The output produced by a key-derivation method using input that includes the shared secret created during the execution of any key-establishment scheme specified in this Recommendation shall only be used as secret keying material – such as a symmetric key used for data encryption or message integrity, a secret initialization vector, or, perhaps, a key-derivation key that will be used to generate additional keying material (possibly using a different process – see SP 800-108¹⁶). The derived keying material shall not be used as a key stream for a stream cipher. Non-secret keying material (such as a non-secret initialization vector) shall not be generated using a key-derivation method that includes the shared secret, \(Z\), as input (this restriction applies to all one-step and two-step key-derivation methods in SP 800-56C).

Approved methods for key derivation from a shared secret are specified in SP 800-56C. These methods can be accessed using the following call:

where

1. \(Z\) is a byte string that represents the shared secret,

2. \(\mathit{OtherInput}\) consists of additional input information that may be required by a given key-derivation method, for example:

• \(L\) − an integer that indicates the bit length of the secret keying material to be derived,

• \(\mathit{salt}\) − a byte string,

• \(\mathit{IV}\) – a bit string used as an initialization value, and

• \(\mathit{FixedInfo}\) – a bit sting of context-specific data (see Section 5.5.2).

See SP 800-56C for details concerning the appropriate form of \(\mathit{OtherInput}\).

The bit string \(\mathit{FixedInfo}\) 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-establishment schemes.

Context-specific information that may be appropriate for inclusion in \(\mathit{FixedInfo}\) includes the following:

• Agreed-upon encodings (as bit strings) of the values of one or more of the other parameters used as additional input to the KDM (e.g., \(L\), \(\mathit{salt}\), and/or \(\mathit{IV}\)).

• An indication of various parameter or primitive choices (e.g., hash functions, MAC algorithms, \(\mathit{MacTag}\) lengths used for key confirmation, etc.).

For rationale in support of including entity identifiers, scheme identifiers, and/or other information in \(\mathit{OtherInput}\), see Appendix B of SP 800-56A.

When \(\mathit{FixedInfo}\) is used, the meaning of each information item and each item’s position within the \(\mathit{FixedInfo}\) bit string shall be specified. In addition, each item of information included in \(\mathit{FixedInfo}\) shall be unambiguously represented. For example, each item of information could take the form of a fixed-length bit string, or, if greater flexibility is needed, an item of information could be represented in a \(\mathit{Datalen} \parallel \mathit{Data}\) format, where \(\mathit{Data}\) is a variable-length string of zero or more (eight-bit) bytes, and \(\mathit{Datalen}\) is a fixed-length, big-endian counter that indicates the byte length of \(\mathit{Data}\). These requirements can be satisfied, for example, by using ASN.1 DER encoding as specified in Section 5.5.2.1.2.

Recommended formats for \(\mathit{FixedInfo}\) when used by a one-step key-derivation method are specified in Sections 5.5.2.1.1 and 5.5.2.1.2. One of those two formats should be used by a one-step key-derivation method specified in SP 800-56C when the auxiliary function employed is \(\mathrm{H} = \mathit{hash}\).

When \(\mathit{FixedInfo}\) is included during the key-derivation process, and the recommended formats are used, the included items of information shall be divided into (three, four, or five) subfields as defined below.

\(\mathit{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, \(\mathit{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.

\(\mathit{PartyUInfo}\): A required non-null subfield containing public information about party U. At a minimum, \(\mathit{PartyUInfo}\) shall include \(\mathit{ID}_U\), 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.

\(\mathit{PartyVInfo}\): A required non-null subfield containing public information about party V. At a minimum, \(\mathit{PartyVInfo}\) shall include \(\mathit{ID}_V\), an identifier for party V, as a distinct item of information. This subfield could also include information about the public key contributed to the key-establishment transaction by party V. When the key-derivation method is used in a KAS1 scheme (see Section 8.2), the nonce, \(N_V\), supplied by party V shall be included in this field.

\(\mathit{SuppPubInfo}\): An optional subfield that contains additional, mutually known public information (e.g., \(L\), 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 \(\mathit{Null}\) for a given transaction.

\(\mathit{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 \(\mathit{Null}\) for a given transaction.

5.5.2.1.1 The Concatenation Format for \(\mathit{FixedInfo}\)

This section specifies the concatenation format for \(\mathit{FixedInfo}\). This format has been designed to provide a simple means of binding the derived keying material to the context of the key-establishment transaction, independent of other actions taken by the relying application. Note: When the one-step key-derivation method specified in SP 800-56C is used with \(\mathrm{H} = \mathit{hash}\) as the auxiliary function and this concatenation format for \(\mathit{FixedInfo}\), the resulting key-derivation method is the Concatenation Key-Derivation Function specified in the original version of SP 800-56A.

For this format, \(\mathit{FixedInfo}\) is a bit string equal to the following concatenation:

where the five subfields are bit strings comprised of items of information as described in Section 5.5.2.1.

Each of the three required subfields \(\mathit{AlgorithmID}\), \(\mathit{PartyUInfo}\), and \(\mathit{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 \(\mathit{Datalen} \parallel \mathit{Data}\) – where \(\mathit{Data}\) is a variable-length string of zero or more (eight-bit) bytes, and \(\mathit{Datalen}\) is a fixed-length, big-endian counter that indicates the byte length of \(\mathit{Data}\). (In this variable-length format, a null string of data shall be represented by a zero value for \(\mathit{Datalen}\), indicating the absence of following data.) A protocol using this format for \(\mathit{FixedInfo}\) shall specify the number, ordering and meaning of the information-bearing substrings that are included in each of the subfields (i.e., \(\mathit{AlgorithmID}\), \(\mathit{PartyUInfo}\), and \(\mathit{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 \(\mathit{Datalen}\) counters.

Each of the optional \(\mathit{SuppPrivInfo}\) and \(\mathit{SuppPubInfo}\) subfields (when allowed by the protocol employing the one-step key-derivation method) 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 \(\mathit{Datalen} \parallel \mathit{Data}\), where \(\mathit{Data}\) is a variable-length string of zero or more (eight-bit) bytes, and \(\mathit{Datalen}\) is a fixed-length, big-endian counter that indicates the byte length of \(\mathit{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 \(\mathit{SuppPrivInfo}\) or \(\mathit{SuppPubInfo}\) subfield. The substrings representing items of information that parties U and V choose not to contribute are set equal to \(\mathit{Null}\), and are represented in this variable-length format by setting \(\mathit{Datalen}\) equal to zero. If a protocol allows the use of the \(\mathit{FixedInfo}\) subfield \(\mathit{SuppPrivInfo}\) and/or the subfield \(\mathit{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 \(\mathit{Datalen}\) counters.

5.5.2.1.2 The ASN.1 Format for \(\mathit{FixedInfo}\)

The ASN.1 format for \(\mathit{FixedInfo}\) provides an alternative means of binding the derived keying material to the context of the key-establishment transaction, independent of other actions taken by the relying application. Note: When the one-step key-derivation method specified in SP 800-56C is used with \(\mathrm{H} = \mathit{hash}\) as the auxiliary function and with this ASN.1 format for \(\mathit{FixedInfo}\), the resulting key-derivation method is the ASN.1 Key-Derivation Function specified in the original version of SP 800-56B.

For the ASN.1 format, \(\mathit{FixedInfo}\) is a bit string resulting from the ASN.1 Distinguished Encoding Rules (DER) encoding (see ISO/IEC 8825-1) of a data structure comprised of a sequence of three required subfields \(\mathit{AlgorithmID}\), \(\mathit{PartyUInfo}\), and \(\mathit{PartyVInfo}\), and, optionally, a subfield \(\mathit{SuppPubInfo}\) and/or a subfield \(\mathit{SuppPrivInfo}\) – as described in Section 5.5.2.1. A protocol using this format for \(\mathit{FixedInfo}\) shall specify the type, ordering and number of distinct items of information included in each of the (three, four, or five) subfields employed.

For the two-step key-derivation method specified in SP 800-56C, \(\mathit{FixedInfo}\) is a bit string that contains component data fields such as a \(\mathit{Label}\), \(\mathit{Context}\) information, and \([L]_2\), where:

• \(\mathit{Label}\) is a binary string that identifies the purpose of the derived keying material. The encoding method for the label is defined in a larger context, for example, in a protocol using the derivation method.

• \(\mathit{Context}\) is a binary string containing information relating to the derived keying material. Section 5.5.2 provides a list of context-specific information that may be appropriate for the inclusion in this string.

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

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

5.5.2.3 Other Formats for \(\mathit{FixedInfo}\)

Formats other than those provided in Sections 5.5.2.1 and 5.5.2.2 (e.g., those providing the items of information in a different arrangement) may be used for \(\mathit{FixedInfo}\), but the context-specific information described in the preceding sections should be included (see the discussion in Section 5.5.2). This Recommendation makes no statement as to the adequacy of other formats.

As specified in this Recommendation, unilateral key confirmation occurs when one participant in the execution of a key-establishment scheme (the key-confirmation “provider”) demonstrates to the satisfaction of the other participant (the key-confirmation “recipient”) that both the KC provider and the KC recipient have possession of the same secret \(\mathit{MacKey}\).

\(\mathit{MacKey}\) shall be a symmetric key that is unique to a specific execution of a key-establishment scheme and (from the perspective of the KC provider) shall be unpredictable prior to that key-establishment transaction. In the case of a key-agreement scheme, \(\mathit{MacKey}\) is derived using the shared secret \(Z\) created during the execution of that scheme (see Section 5.5 for the details of key derivation). In the case of a key-transport scheme, \(\mathit{MacKey}\) is included as part of the transported keying material. Step_2 below specifies how \(\mathit{MacKey}\) is to be extracted from the derived or transported keying material.

\(\mathit{MacKey}\) and certain context-specific \(\mathit{MacData}\) (as specified below) are used by the KC provider as input to an approved MAC algorithm to obtain a MAC tag that is sent to the KC recipient. The recipient performs an independent computation of the MAC tag. If the MAC tag value computed by the KC recipient matches the MAC tag value received from the KC provider, then key confirmation is successful. (See Section 5.2 for MAC-tag generation and verification, and Section 5.6.3 for a discussion of MAC-tag security.)

In the case of a scheme providing key-agreement, successful key confirmation following key agreement provides assurance to the KC recipient that the same \(Z\) value has been used by both parties to correctly derive the keying material (which includes \(\mathit{MacKey}\)). In the case of a key-transport scheme (see Section 9.2.4), successful key confirmation provides assurance to the KC recipient (who sent the keying material) that the transported keying material (which includes \(\mathit{MacKey}\)) has been correctly decrypted by the party to whom it was sent.

A close examination of the KC process shows that each of the pair-wise key-establishment schemes specified in this Recommendation that incorporate key confirmation can be used to provide the KC recipient with assurance that the KC provider is currently in possession of the (correct) private key – the one corresponding to the KC provider’s public key-establishment key. The use of transaction-specific values for both \(\mathit{MacKey}\) and \(\mathit{MacData}\) prevents (for all practical purposes) the replay of any previously computed value of \(\mathit{MacTag}\). The receipt of a correctly computed MAC tag provides assurance to the KC recipient that the KC provider has used the correct private key during the current transaction – to successfully recover the secret data that is a prerequisite to learning the value of \(\mathit{MacKey}\).

To include unilateral key confirmation, the following steps shall be incorporated into the scheme. (Additional details will be provided for each scheme in the appropriate subsections of Sections 8 and 9.) In the discussion that follows, the key-confirmation provider, P, may be either 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.

– \(\mathit{message\_string}_P\) 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).

– \(\mathit{ID}_P\) is the identifier used to label the key-confirmation provider.

– \(\mathit{ID}_R\) is the identifier used to label the key-confirmation recipient.

– \(\mathit{EphemData}_P\) and \(\mathit{EphemData}_R\) 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.

– \(\mathit{Text}_P\) 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 \(\mathit{MacData}_P\) shall be precisely defined and unambiguously represented. A particular component’s content may be represented, for example, as a fixed-length bit string or in the form \(\mathit{Datalen} \parallel \mathit{Data}\), where \(\mathit{Data}\) is a variable-length string of zero or more (eight-bit) bytes, and \(\mathit{Datalen}\) is a fixed-length, big-endian counter that indicates the length (in bytes) of \(\mathit{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 \(\mathit{MacData}_P\).

\(\mathit{MacData}\) shall include a non-null identifier, \(\mathit{ID}_P\), for the key-confirmation provider.

Depending upon the circumstances, the key-confirmation recipient’s identifier, \(\mathit{ID}_R\), may be replaced by a null string. The rules for selecting \(\mathit{ID}_P\) and \(\mathit{ID}_R\) 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 or KTS-OAEP-basic) that determines the \(\mathit{MacKey}\) value used in the key-confirmation computations performed during the transaction. The identifier, \(\mathit{ID}_p\), included in \(\mathit{MacData}_P\) shall be one that has a trusted association with the public key of that key pair.

For the KAS2 family of schemes, the identifier of the key-confirmation recipient included in \(\mathit{MacData}_P\) (i.e., \(\mathit{ID}_R\)) shall be one that has a trusted association with the public key of the key pair used by the key-confirmation recipient during the transaction.

If the key-confirmation recipient does not own a key pair employed for key-establishment 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 \(\mathit{ID}_R\) 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 \(\mathit{ID}_R\), shall be selected/assigned in accordance with the requirements of the protocol relying upon the transaction.

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 \(\mathit{ID}_P\) or \(\mathit{ID}_R\), respectively, in the \(\mathit{MacData}_P\) used during key confirmation. For example, if party U is the key-confirmation recipient, and \(\mathit{ID}_U\) has been used to label party U in the \(\mathit{FixedInfo}\) employed by the key-derivation method of a key-agreement scheme used during the transaction, then the \(\mathit{MacData}_P\) used during key confirmation shall have \(\mathit{ID}_R = \mathit{ID}_U\).

2. When a KAS1 or KAS2 key-agreement scheme is used: After computing the shared secret \(Z\) and applying the key-derivation function to obtain the derived keying material, \(\mathit{DerivedKeyingMaterial}\) (see Section 5.5), the KC provider uses agreed-upon bit lengths to parse \(\mathit{DerivedKeyingMaterial}\) into two parts, \(\mathit{MacKey}\) and \(\mathit{KeyData}\):

When the KTS-OAEP key-transport scheme is used: The KC provider parses the \(\mathit{TransportedKeyingMaterial}\) into \(\mathit{MacKey}\) and \(\mathit{KeyData}\):

3. Using an agreed-upon bit length \(\mathit{MacTagBits}\), the KC provider computes \(\mathit{MacTag}_P\) (see Sections 5.2.1 and 5.6.3):

and sends it to the KC recipient.

4. The KC recipient forms \(\mathit{MacData}_P\), determines \(\mathit{MacKey}\), computes \(\mathit{MacTag}_P\) in the same manner as the KC provider, and then compares its computed \(\mathit{MacTag}_P\) to the value received from the provider. If the received value is equal to the computed value, then the recipient is assured that the provider has used the same value for \(\mathit{MacKey}\) and that the provider shares the recipient’s value of \(\mathit{MacTag}_P\).

Each participant shall destroy all copies of the \(\mathit{MacKey}\) that was employed for key-confirmation purposes during a particular pair-wise key-establishment transaction when \(\mathit{MacKey}\) is no longer needed to provide or obtain key confirmation as part of that transaction.

If \(\mathit{MacTag}_P\) cannot be verified by the KC recipient during a particular key-establishment transaction, then key confirmation has failed, and both participants shall destroy all of their copies of \(\mathit{MacKey}\) and \(\mathit{KeyData}\). In particular, \(\mathit{MacKey}\) and \(\mathit{KeyData}\) shall not be revealed by either participant to any other party (not even to the other participant), and the keying material shall not be used for any further purpose. In the case of a key-confirmation failure, the key-establishment transaction shall be terminated.

Note: The key-confirmation routines employed by the KC provider and KC recipient shall destroy all local copies of \(\mathit{MacKey}\), \(\mathit{MacData}\), destroyable copies of \(\mathit{KeyData}\) and any other locally stored values used or produced during the execution of those routines. The destruction of those locally stored values shall occur prior to or during any exit from those routines – whether exiting normally or exiting early, because of an error.

Bilateral key confirmation, as specified in this Recommendation, can be incorporated into a KAS2 key-agreement scheme since each party is required to own a key-establishment key pair that is used in the key-agreement process. Bilateral key confirmation is accomplished by performing unilateral key confirmation in both directions (with party U providing \(\mathit{MacTag}_U\) to KC recipient V, and party V providing \(\mathit{MacTag}_V\) to KC recipient U) during the same scheme.

To include bilateral key confirmation, two instances of unilateral key confirmation (as specified in Section 5.6.1, subject to the modifications listed below) shall be incorporated into the KAS2 scheme, once with party U as the key-confirmation provider (i.e., \(\mathrm{P} = \mathrm{U}\) and \(\mathrm{R} = \mathrm{V}\)) and once with party V as the key-confirmation provider (i.e., \(\mathrm{P} = \mathrm{V}\) and \(\mathrm{R} = \mathrm{U}\)). Additional details will be provided in Section 8.3.3.4. In addition to setting \(\mathrm{P} = \mathrm{U}\) and \(\mathrm{R} = \mathrm{V}\) in one instance of the unilateral key-confirmation procedure described in Section 5.6.1 and setting \(\mathrm{P} = \mathrm{V}\) and \(\mathrm{R} = \mathrm{U}\) in a second instance, the following changes/clarifications apply when using the procedure for bilateral key confirmation:

1. When computing \(\mathit{MacTag}_U\), the value of \(\mathit{message\_string}_U\) that forms the initial segment of \(\mathit{MacData}_U\) is the six-byte character string “KC_2_U”.

2. When computing \(\mathit{MacTag}_V\), the value of \(\mathit{message\_string}_V\) that forms the initial segment of \(\mathit{MacData}_V\) is the six-byte character string “KC_2_V”.

3. If used at all, the value of the (optional) byte string \(\mathit{Text}_U\) used to form the final segment of \(\mathit{MacData}_U\) can be different than the value of the (optional) byte string \(\mathit{Text}_V\) used to form the final segment of \(\mathit{MacData}_V\), provided that both parties are aware of the value(s) used.

4. The identifiers used to label the parties U and V when forming \(\mathit{MacData}_U\) shall be the same as the identifiers used to label the parties U and V when forming \(\mathit{MacData}_V\), although \(\mathit{ID}_U\) and \(\mathit{ID}_V\) will play different roles in the two strings. If \(\mathit{ID}_P = \mathit{ID}_U\) and \(\mathit{ID}_R = \mathit{ID}_V\) are used in \(\mathit{MacData}_U\), then \(\mathit{ID}_P = \mathit{ID}_V\) and \(\mathit{ID}_R = \mathit{ID}_U\) are used in \(\mathit{MacData}_V\).

Key confirmation as specified in this Recommendation requires that a \(\mathit{MacKey}\) of an appropriate length be generated or obtained as part of the derived keying material (see Section 5.6.1). The \(\mathit{MacKey}\) is then used with a MAC algorithm to generate a MAC; the length of the MAC output by the MAC algorithm is \(\mathit{MacOutputBits}\) bits. The MAC is subsequently used to form a MAC tag (see Section 5.6.1 for the generation of the MAC and Section 5.2.1 for the formation of the MAC tag from the MAC). Table 1 provides a list of approved MAC algorithms for key confirmation and the security strengths that each can support, along with the corresponding value of \(\mathit{MacOutputBits}\) and permissible \(\mathit{MacKey}\) lengths for each MAC algorithm.

The MAC algorithm used to compute a key-confirmation MAC tag in compliance with this Recommendation shall be selected from among the approved MAC algorithms capable of supporting a security strength \(s\) that is at least as large as the targeted security strength of the key-establishment scheme (as indicated in Table 1 above).

Note that when the HMAC or KMAC algorithm is used for key confirmation as specified in this Recommendation, \(\mathit{MacKey}\) lengths can be no greater than 512 bits (an upper bound that is at least twice the maximum supported security strength). Although the HMAC and KMAC specifications permit the use of longer keys, the 512-bit maximum is sufficient for this key-confirmation application. In the case of HMAC, the 512-bit upper bound has the advantage of being less than or equal to the input block length of whatever hash function is used in the algorithm’s implementation. If \(\mathit{MacKey}\) were allowed to be longer than the input block length, it would be hashed down to a string of length \(\mathit{MacOutputBits}\) during the HMAC computation (see step 2 in Table 1 of FIPS 198); allowing \(\mathit{MacKey}\) to be longer than the input block length would not be an efficient use of keying material.

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

A valid RSA key pair, in its basic form, shall consist of an RSA public key \((n, e)\) and an RSA private key \((n, d)\), where:

1. \(n\), the public modulus, shall be the product of exactly two distinct, odd positive prime factors, \(p\) and \(q\), that are kept secret. Let \(\operatorname{len}(n) = \mathit{nBits}\), the bit length of \(n\); \(\operatorname{len}(n)\) is required to be even.

2. The public exponent \(e\) shall be an odd integer that is selected prior to the generation of \(p\) and \(q\) such that:

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:
a. \(2^{(\mathit{nBits} - 1)/2} < p < 2^{\mathit{nBits}/2}\).
b. \(2^{(\mathit{nBits} - 1)/2} < q < 2^{\mathit{nBits}/2}\).
c. \(|p - q| > 2^{\mathit{nBits}/2 - 100}\).

d. The exponent \(e\) must be mutually prime with both \(p - 1\) and \(q - 1\):

4. The primes \(p\) and \(q\), and the private exponent \(d\) shall be selected such that:
a. \(2^{\mathit{nBits}/2} < d < \operatorname{LCM}(p-1, q-1)\), and
b. \(d = e^{-1} \bmod (\operatorname{LCM}(p-1, q-1))\).
Regarding step 4a: One can be certain that the inequality \(2^{\mathit{nBits}/2} < d\) will be satisfied even before \(d\) is computed by verifying that \(\operatorname{LCM}(p-1, q-1) \ge (e)(2^{\mathit{nBits}/2})\). The second inequality, \(d < \operatorname{LCM}(p-1, q-1)\), will be satisfied if \(d\) is computed as specified in step b).

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 to specify the RSA primitives and operations in Section 7. 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)\).

2. The prime-factor format: \((p, q, d)\).

3. The Chinese Remainder Theorem (CRT) format: \((n, e, d, p, q, \mathit{dP}, \mathit{dQ}, \mathit{qInv})\), where \(\mathit{dP} = d \bmod (p - 1)\), \(\mathit{dQ} = d \bmod (q - 1)\), and \(\mathit{qInv} = q^{-1} \bmod p\). Note that Section 7.1.2 discusses the use of the private key expressed using the CRT format during the execution of the RSA decryption primitive.

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. Note that these generation methods ensure that the prime factors \(p\) and \(q\) have the same bit length and that their product, \(n\) (the RSA modulus), has a bit length that is exactly twice the length of its factors. An approved RSA key-pair generator and approved random bit generator (RBG) shall be used to produce an RSA key pair. Any modulus with an even bit length that provides at least 112 bits of security strength may be used. Commonly used modulus lengths and their associated security strengths are given in Table 2. For other modulus lengths, Appendix D provides a method for estimating the security strength that can be supported. Table 2: Security Strengths Supported by Commonly Used Modulus Lengths¹⁷

Approved RBGs are discussed in Section 5.3. The approved RSA key-pair generators are provided in Sections 6.3.1 and 6.3.2, and 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. For the following methods in Section 6.3 and the assurances in Section 6.4, let \(\mathrm{ES}(\mathit{nBits})\) denote the estimated maximum security strength for a modulus of bit length \(\mathit{nBits}\) as determined by Table 2 or Appendix D.

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, \mathit{dP}, \mathit{dQ}, \mathit{qInv})\).

rsakpg1-basic is the generator in the RSAKPG1 family where the private key is in the basic format \((n, d)\).

Function call: \(\textit{rsakpg1-basic}(s, \mathit{nBits}, e)\)
Input:

1. \(s\): the targeted security strength;

2. \(\mathit{nBits}\): the intended bit length of the RSA modulus; and

3. \(e\): a pre-determined public exponent − an odd integer, such that \(65{,}537 \le e < 2^{256}\).

a. If \(s\) is not in the range \([112, 256]\), output an indication that the targeted security strength is not acceptable, and exit without further processing.
b. If \(s > \mathrm{ES}(\mathit{nBits})\), output an indication that the modulus length is not adequate for the targeted security strength, and exit without further processing.
c. If \(e\) is not an odd integer such that \(65{,}537 \le e < 2^{256}\), 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. Note that the routines ensure that \(p - 1\) and \(q - 1\) are relatively prime to \(e\).

3. Determine the private exponent \(d\):

In the very rare event that \(d \le 2^{\mathit{nBits}/2}\), discard the results of all computations and repeat the process, starting at step 2.

4. Determine the modulus \(n\) as \(n = p \times q\), the product of \(p\) and \(q\).

5. Perform a pair-wise consistency test¹⁸ by verifying that \(m\) is the same as \((m^e)^d \bmod n\) for some integer \(m\) satisfying \(1 < m < (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.

1. \((n, e)\): the RSA public key, and

2. \((n, d)\): the RSA private key in the basic format.

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 the execution of the routine. The destruction of these locally stored values 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.

rsakpg1-prime-factor is the generator in the RSAKPG1 family such that the private key is in the prime factor format \((p, q, d)\).
Function call: \(\textit{rsakpg1-prime-factor}(s, \mathit{nBits}, e)\)
The inputs, outputs and errors are the same as in rsakpg1-basic (see Section 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 during the validation process, 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 the execution of the routine. The destruction of these locally stored values 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.

rsakpg1-crt is the generator in the RSAKPG1 family such that the private key is in the Chinese Remainder Theorem format \((n, e, d, p, q, \mathit{dP}, \mathit{dQ}, \mathit{qInv})\).
Function call: \(\textit{rsakpg1-crt}(s, \mathit{nBits}, e)\)
The inputs, outputs and errors are the same as in rsakpg1-basic (see Section 6.3.1.1) except that the private key is in the Chinese Remainder Theorem format: \((n, e, d, p, q, \mathit{dP}, \mathit{dQ}, \mathit{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 \(\mathit{dP}\), \(\mathit{dQ}\) and \(\mathit{qInv}\):

a. \(\mathit{dP} = d \bmod (p - 1)\).
b. \(\mathit{dQ} = d \bmod (q - 1)\).
c. \(\mathit{qInv} = q^{-1} \bmod p\).

6. Perform a pair-wise consistency test¹⁹ by verifying that \(m = (m^e)^d \bmod n\) for some integer \(m\) satisfying \(1 < m < (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, \mathit{dP}, \mathit{dQ}, \mathit{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 during the validation process, 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\), \(\mathit{dP}\), \(\mathit{dQ}\), \(\mathit{qInv}\), and \(d\), as well as any other locally stored values used or produced during the execution of the routine. The destruction of these locally stored values 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.

The RSAKPG2 family of key-pair generation methods consists of three RSA key-pair generators such that the public exponent \(e\) is a random value in the range \(65{,}537 \le e < 2^{256}\).
Three representations are addressed:

1. rsakpg2-basic generates the private key in the basic format \((n, d)\);

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, \mathit{dP}, \mathit{dQ}, \mathit{qInv})\).

rsakpg2-basic is the generator in the RSAKPG2 family such that the private key is in the basic format \((n, d)\).
Function call: \(\textit{rsakpg2-basic}(s, \mathit{nBits}, \mathit{eBits})\)
Input:

1. \(s\): the targeted security strength;

2. \(\mathit{nBits}\): the intended bit length of the RSA modulus; and

3. \(\mathit{eBits}\): the intended bit length of the public exponent – an integer such that \(17 \le \mathit{eBits} \le 256\). Note that the public exponent shall be an odd integer such that \(65{,}537 \le e < 2^{256}\).

a. If \(s\) is not in the range \([112, 256]\), output an indication that the targeted security strength is not acceptable, and exit without further processing.
b. If \(s > \mathrm{ES}(\mathit{nBits})\), output an indication that the modulus length is not adequate for the targeted security strength, and exit without further processing.
c. If \(\mathit{eBits}\) is not an integer such that \(17 \le \mathit{eBits} \le 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 \([2^{\mathit{eBits}-1} + 1, 2^{\mathit{eBits}} - 1]\) using an approved RBG (see Section 5.3).

3. Generate the prime factors \(p\) and \(q\) as specified in FIPS 186. Note that the routines ensure that \(p - 1\) and \(q - 1\) are relatively prime to \(e\).

4. Determine the private exponent \(d\):

In the event that no such \(d\) exists, or in the very rare event that \(d \le 2^{\mathit{nBits}/2}\), discard the results of all computations and repeat the process, starting at step 2.

5. Determine the modulus \(n\) as \(n = p \times q\), the product of \(p\) and \(q\).

6. Perform a pair-wise consistency test²⁰ by verifying that \(m\) is the same as \((m^e)^d \bmod n\) for some integer \(m\) satisfying \(1 < m < (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.

1. \((n, e)\): the RSA public key; and

2. \((n, d)\): the RSA private key in the basic format.

Note that key-pair validation, as specified in Section 6.4.1.3.1, can be performed after step 6 and before step 7 of the process above. If an error is detected during the validation process, 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 the execution of the routine. The destruction of these locally stored values 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.

rsakpg2-prime-factor is the generator in the RSAKPG2 family such that the private key is in the prime-factor format \((p, q, d)\).
Function call: \(\textit{rsakpg2-prime-factor}(s, \mathit{nBits}, \mathit{eBits})\)
The inputs, outputs and errors are the same as in rsakpg2-basic (see Section 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 during the validation process, 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 the execution of the routine. The destruction of these locally stored values 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.

rsakpg2-crt is the generator in the RSAKPG2 family such that the private key is in the Chinese Remainder Theorem format \((n, e, d, p, q, \mathit{dP}, \mathit{dQ}, \mathit{qInv})\).
Function call: \(\textit{rsakpg2-crt}(s, \mathit{nBits}, \mathit{eBits})\)
The inputs, outputs and errors are the same as in rsakpg2-basic (see Section 6.3.2.1) except that the private key is in the Chinese Remainder Theorem format: \((n, e, d, p, q, \mathit{dP}, \mathit{dQ}, \mathit{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 \(\mathit{dP}\), \(\mathit{dQ}\) and \(\mathit{qInv}\):

a. \(\mathit{dP} = d \bmod (p - 1)\).
b. \(\mathit{dQ} = d \bmod (q - 1)\).
c. \(\mathit{qInv} = q^{-1} \bmod p\).

7. Perform a pair-wise consistency test²¹ by verifying that \(m\) is the same as \((m^e)^d \bmod n\) for some integer \(m\) satisfying \(1 < m < (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, \mathit{dP}, \mathit{dQ}, \mathit{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 during the validation process, 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\), \(\mathit{dP}\), \(\mathit{dQ}\), \(\mathit{qInv}\), and \(d\), as well as any other locally stored values used or produced during the execution of the routine. The destruction of these locally stored values 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. Key-pair consistency: The owner shall perform a pair-wise consistency test by verifying that \(m = (m^e)^d \bmod n\) for some integer \(m\) satisfying \(1 < m < (n - 1)\). Note that if the owner generated the key pair (see method 1.a above), an initial pair-wise consistency test was performed during key-pair generation (see Section 6.3). If a TTP generated the key pair and provided it to the owner (see method 1.b above), the owner shall perform the consistency check separately, prior to the first use of the key pair in a key-establishment transaction (see Section 4.1).

1. Perform a pair-wise consistency test by verifying that \(m = (m^e)^d \bmod n\) for some integer \(m\) satisfying \(1 < m < (n - 1)\), and

rsakpv1-basic is the key-pair validation method corresponding to rsakpg1-basic (see Section 6.3.1.1).
Function call: \(\mathit{rsakpv1\text{-}basic}\,(s, \mathit{nBits}, e_{\mathit{fixed}}, (n_{\mathit{pub}}, e_{\mathit{pub}}), (n_{\mathit{priv}}, d))\)
Input:

1. \(s\): the targeted security strength;

2. \(\mathit{nBits}\): the intended bit length of the RSA modulus;

3. \(e_{\mathit{fixed}}\): the intended fixed public exponent – an odd integer such that \(65{,}537 \le e_{\mathit{fixed}} < 2^{256}\);

4. \((n_{\mathit{pub}}, e_{\mathit{pub}})\): the RSA public key to be validated; and

5. \((n_{\mathit{priv}}, d)\): the RSA private key to be validated in the basic format.

1. Check the sizes of \(s\) and \(e_{\mathit{fixed}}\):

a. If \(s\) is not in the interval \([112, 256]\), output an indication that the security strength is not acceptable, and exit without further processing.
b. If \(s > \mathrm{ES}(\mathit{nBits})\), output an indication that the modulus length is not adequate for the intended security strength, and exit without further processing.
c. If \(e_{\mathit{fixed}}\) is not an odd integer such that \(65{,}537 \le e_{\mathit{fixed}} < 2^{256}\), output an indication that the fixed public exponent is out of range, and exit without further processing.

If \(e_{\mathit{pub}} \ne e_{\mathit{fixed}}\), output an indication of an invalid key pair, and exit without further processing.

a. If \(n_{\mathit{pub}} \ne n_{\mathit{priv}}\), output an indication of an invalid key pair, and exit without further processing.

b. If \(\operatorname{len}(n_{\mathit{pub}}) \ne \mathit{nBits}\), output an indication of an invalid key pair, and exit without further processing.

c. If \(\mathit{nBits}\) is not a positive even integer, output an indication of an invalid key pair, and exit without further processing.

a. Recover the prime factors \(p\) and \(q\) from the modulus \(n_{\mathit{pub}}\), the public exponent \(e_{\mathit{pub}}\) and the private exponent \(d\) (using one of the methods in Appendix C):

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 \(n_{\mathit{pub}} \ne p \times q\), then output an indication that the request is invalid, and exit without further processing.

a. If \((p < (\sqrt{2})(2^{\mathit{nBits}/2-1}))\) or \((p > 2^{\mathit{nBits}/2} - 1)\), output an indication of an invalid key pair, and exit without further processing.

b. If \((q < (\sqrt{2})(2^{\mathit{nBits}/2-1}))\) or \((q > 2^{\mathit{nBits}/2} - 1)\), output an indication of an invalid key pair, and exit without further processing.
c. If \(|p - q| \le 2^{(\mathit{nBits}/2-100)}\), output an indication of an invalid key pair, and exit without further processing.
d. If \(\operatorname{GCD}(p - 1, e_{\mathit{pub}}) \ne 1\), output an indication of an invalid key pair, and exit without further processing.

e. If \(\operatorname{GCD}(q - 1, e_{\mathit{pub}}) \ne 1\), output an indication of an invalid key pair, and exit without further processing.

f. Apply an approved primality test* to the factor \(p\) (see FIPS 186, Appendices C.3 and E). If the primality test indicates that \(p\) is not prime, output an indication of an invalid key pair, and exit without further processing.
g. Apply an approved primality test* to the factor \(q\) (see FIPS 186, Appendices C.3 and E). If the primality test indicates that \(q\) is not prime, output an indication of an invalid key pair, and exit without further processing.
* Relying parties (and/or agents trusted to act on their behalf) shall determine which of the approved primality tests in FIPS 186 meet their security requirements. The probability that \(p\) or \(q\) may be incorrectly classified as prime by the test used in step 5 shall be less than or equal to \(2^{-\mathrm{ES}(\mathit{nBits})}\).

6. Check that the private exponent \(d\) satisfies
a. \(2^{\mathit{nBits}/2} < d < \operatorname{LCM}(p - 1, q - 1)\).

and
b. \(1 = (d \times e_{\mathit{pub}}) \bmod \operatorname{LCM}(p - 1, q - 1)\).

1. \(\mathit{status}\): An indication that the key pair is valid or an indication of an error.

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 the execution of the routine. The destruction of these locally stored values shall occur prior to or during any exit from the routine (whether exiting early because of an error, or exiting normally).

rsakpv1-prime-factor is the key-pair validation method corresponding to rsakpg1-prime-factor (see Section 6.3.1.2).
Function call: rsakpv1-prime-factor \((s, \mathit{nBits}, e_{\mathit{fixed}}, (n_{\mathit{pub}}, e_{\mathit{pub}}), (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 except that in processing:
A. Step 3 is replaced by the following:

a. If \(n_{\mathit{pub}} \ne p \times q\), output an indication of an invalid key pair, and exit without further processing.

b. If \(\operatorname{len}(n_{\mathit{pub}}) \ne \mathit{nBits}\), output an indication of an invalid key pair, and exit without further processing.

c. If \(\mathit{nBits}\) is not a positive even integer, 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 the execution of the routine. The destruction of these locally stored values shall occur prior to or during any exit from the routine (whether exiting early because of an error, or exiting normally).

rsakpv1-crt is the key-pair validation method corresponding to rsakpg1-crt.
Function call: rsakpv1-crt \((s, \mathit{nBits}, e_{\mathit{fixed}}, (n_{\mathit{pub}}, e_{\mathit{pub}}), (n_{\mathit{priv}}, e_{\mathit{priv}}, d, p, q, \mathit{dP}, \mathit{dQ}, \mathit{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: \((n_{\mathit{priv}}, e_{\mathit{priv}}, d, p, q, \mathit{dP}, \mathit{dQ}, \mathit{qInv})\).

If \((e_{\mathit{pub}} \ne e_{\mathit{fixed}})\) or \((e_{\mathit{pub}} \ne e_{\mathit{priv}})\), output an indication of an invalid key pair, and exit without further processing.

a. If \(n_{\mathit{pub}} \ne p \times q\), or \(n_{\mathit{pub}} \ne n_{\mathit{priv}}\), output an indication of an invalid key pair, and exit without further processing.

b. If \(\operatorname{len}(n_{\mathit{pub}}) \ne \mathit{nBits}\), output an indication of an invalid key pair, and exit without further processing.

c. If \(\mathit{nBits}\) is not a positive even integer, output an indication of an invalid key pair, and exit without further processing.

7. Check the CRT components: Check that the components \(\mathit{dP}\), \(\mathit{dQ}\) and \(\mathit{qInv}\) satisfy

a. \(1 < \mathit{dP} < (p - 1)\).
b. \(1 < \mathit{dQ} < (q - 1)\).
c. \(1 < \mathit{qInv} < p\).
d. \(1 = (\mathit{dP} \times e_{\mathit{fixed}}) \bmod (p - 1)\).
e. \(1 = (\mathit{dQ} \times e_{\mathit{fixed}}) \bmod (q - 1)\).
f. \(1 = (\mathit{qInv} \times q) \bmod 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.

rsakpv2-basic is the validation method corresponding to rsakpg2-basic (see Section 6.3.2.1).
Function call: rsapkv2-basic \((s, \mathit{nBits}, \mathit{eBits}, (n_{\mathit{pub}}, e_{\mathit{pub}}), (n_{\mathit{priv}}, d))\)

The method is the same as the rsapkv1-basic method in Section 6.4.1.2.1 except that:
A. The \(e_{\mathit{fixed}}\) input parameter is replaced by \(\mathit{eBits}\), which is the intended bit length of the public exponent – an integer such that \(17 \le \mathit{eBits} \le 256\).

B. Step 1c is replaced by:
c. If \((\mathit{eBits} < 17)\) or \((\mathit{eBits} > 256)\), output an indication that the exponent is out of range, and exit without further processing.

If the public exponent \(e_{\mathit{pub}}\) is not odd, or if \(\operatorname{len}(e_{\mathit{pub}}) \ne \mathit{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 the execution of the routine. The destruction of these locally stored values shall occur prior to or during any exit from the routine (whether exiting early because of an error, or exiting normally).

rsakpv2-prime-factor is the key-pair validation method corresponding to the rsakpg2-prime-factor key-pair generation method (see Section 6.3.2.2).
Function call: rsakpv2-prime-factor \((s, \mathit{nBits}, \mathit{eBits}, (n_{\mathit{pub}}, e_{\mathit{pub}}), (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 \(e_{\mathit{fixed}}\) input parameter is replaced by \(\mathit{eBits}\), which is the intended bit length of the public exponent, an integer such that \(17 \le \mathit{eBits} \le 256\).

B. Step 1c is replaced by:
c. If \((\mathit{eBits} < 17)\) or \((\mathit{eBits} > 256)\), output an indication that the exponent is out of range, and exit without further processing.

If the public exponent \(e_{\mathit{pub}}\) is not odd, or if \(\operatorname{len}(e_{\mathit{pub}}) \ne \mathit{eBits}\), output an indication of an invalid key pair, and exit without further processing.

a. If \(n_{\mathit{pub}} \ne p \times q\), output an indication of an invalid key pair, and exit without further processing.

b. If \(\operatorname{len}(n_{\mathit{pub}}) \ne \mathit{nBits}\), output an indication of an invalid key pair, and exit without further processing.

c. If \(\mathit{nBits}\) is not a positive even integer, output an indication of an invalid key pair, and exit without further processing.

E. Step 4 (prime-factor recovery) is omitted (i.e., not used).
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 the execution of the routine. The destruction of these locally stored values shall occur prior to or during any exit from the routine (whether exiting early because of an error or exiting normally).

rsakpv2-crt is the key-pair validation method corresponding to the rsakpg2-crt key-pair generation method (see Section 6.3.1.3).
Function call: rsakpv2-crt \((s, \mathit{nBits}, \mathit{eBits}, (n_{\mathit{pub}}, e_{\mathit{pub}}), (n_{\mathit{priv}}, e_{\mathit{priv}}, d, p, q, \mathit{dP}, \mathit{dQ}, \mathit{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: \((n_{\mathit{priv}}, e_{\mathit{priv}}, d, p, q, \mathit{dP}, \mathit{dQ}, \mathit{qInv})\).

The steps are the same as in rsakpv1-basic (see Section 6.4.1.2.1) except that:
A. The \(e_{\mathit{fixed}}\) input parameter is replaced by \(\mathit{eBits}\), which is the intended bit length of the public exponent, an integer such that \(17 \le \mathit{eBits} \le 256\).

B. Step 1c is replaced by:
c. If (\(\mathit{eBits} < 17\)) or (\(\mathit{eBits} > 256\)), output an indication that the exponent is out of range, and exit without further processing.

If (\(e_{\mathit{pub}} \ne e_{\mathit{priv}}\)) or (\(e_{\mathit{pub}}\) is not odd) or (\(\operatorname{len}(e_{\mathit{pub}}) \ne \mathit{eBits}\)), output an indication of an invalid key pair, and exit without further processing.

a. If (\(n_{\mathit{pub}} \ne p \times q\)) or (\(n_{\mathit{pub}} \ne n_{\mathit{priv}}\)) output an indication of an invalid key pair, and exit without further processing.

b. If \(\operatorname{len}(n_{\mathit{pub}}) \ne \mathit{nBits}\), output an indication of an invalid key pair, and exit without further processing.

c. If \(\mathit{nBits}\) is not a positive even integer, output an indication of an invalid key pair, and exit without further processing.

7. Check the CRT components: Check that the components \(\mathit{dP}\), \(\mathit{dQ}\) and \(\mathit{qInv}\) satisfy

a. \(1 < \mathit{dP} < (p - 1)\).
b. \(1 < \mathit{dQ} < (q - 1)\).
c. \(1 < \mathit{qInv} < p\).
d. \(1 = (\mathit{dP} \times e_{\mathit{pub}}) \bmod (p - 1)\).
e. \(1 = (\mathit{dQ} \times e_{\mathit{pub}}) \bmod (q - 1)\).
f. \(1 = (\mathit{qInv} \times q) \bmod 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.

A routine that implements this validation function shall destroy any local copies of \(p\), \(q\), \(d\), \(\mathit{dP}\), \(\mathit{dQ}\), and \(\mathit{qInv}\), as well as any other locally stored values used or produced during the execution of the routine. The destruction of these locally stored values shall occur prior to or during any exit from the routine (whether exiting early because of an error, or exiting normally).

In this format, the private key is represented as \((n, d)\).
Function call: \(\mathit{basic\_pkv}\ (s, \mathit{nBits}, (n_{\mathit{pub}}, e_{\mathit{pub}}), (n_{\mathit{priv}}, d))\)

The method is the same as the rsapkv1-basic method in Section 6.4.1.2.1 except that:
A. A value for \(e_{\mathit{fixed}}\) is not available as an input parameter.

B. Step 1.c is replaced by:
If \(e_{\mathit{pub}}\) is not an odd integer such that \(65{,}537 \le e_{\mathit{pub}} < 2^{256}\), output an indication that the exponent is out of range, and exit without further processing.

C. Step 2 is omitted (i.e., not used).
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 the execution of the routine. The destruction of these locally stored values shall occur prior to or during any exit from the routine (whether exiting early because of an error or exiting normally).

In this format, the private key is represented as \((p, q, d)\).
Function call: \(\mathit{prime\text{-}factor\_pkv}\ (s, \mathit{nBits}, (n_{\mathit{pub}}, e_{\mathit{pub}}), (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 \(e_{\mathit{fixed}}\) is not available as an input parameter.

B. Step 1.c is replaced by:
If \(e_{\mathit{pub}}\) is not an odd integer such that \(65{,}537 \le e_{\mathit{pub}} < 2^{256}\), output an indication that the exponent is out of range, and exit without further processing.

a. If \(n_{\mathit{pub}} \ne p \times q\), output an indication of an invalid key pair, and exit without further processing.

b. If \(\operatorname{len}(n_{\mathit{pub}}) \ne \mathit{nBits}\), output an indication of an invalid key pair, and exit without further processing.

c. If \(\mathit{nBits}\) is not a positive even integer, output an indication of an invalid key pair, and exit without further processing.

E. Step 4 (prime-factor recovery) is omitted (i.e., not used).
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 the execution of the routine. Their destruction of these values shall occur prior to or during any exit from the routine (whether exiting early because of an error, or exiting normally).

In this format, the private key is represented as \((n, e, d, p, q, \mathit{dP}, \mathit{dQ}, \mathit{qInv})\).
Function call: \(\mathit{crt\_pkv}(s, \mathit{nBits}, (n_{\mathit{pub}}, e_{\mathit{pub}}), (n_{\mathit{priv}}, e_{\mathit{priv}}, d, p, q, \mathit{dP}, \mathit{dQ}, \mathit{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: \((n_{\mathit{priv}}, e_{\mathit{priv}}, d, p, q, \mathit{dP}, \mathit{dQ}, \mathit{qInv})\).

The steps are the same as in rsakpv1-basic (see Section 6.4.1.2.1) except that:
A. A value for \(e_{\mathit{fixed}}\) is not available as an input parameter.

If \(e_{\mathit{pub}}\) is not an odd integer such that \(65{,}537 \le e_{\mathit{pub}} < 2^{256}\), output an indication that the exponent is out of range, and exit without further processing.

a. If \((n_{\mathit{pub}} \ne p \times q)\) or \((n_{\mathit{pub}} \ne n_{\mathit{priv}})\), output an indication of an invalid key pair, and exit without further processing.

b. If \(\operatorname{len}(n_{\mathit{pub}}) \ne \mathit{nBits}\), output an indication of an invalid key pair, and exit without further processing.

c. If \(\mathit{nBits}\) is not a positive even integer, output an indication of an invalid key pair, and exit without further processing.

7. Check the CRT components: Check that the components \(\mathit{dP}\), \(\mathit{dQ}\) and \(\mathit{qInv}\) satisfy

a. \(1 < \mathit{dP} < (p - 1)\).
b. \(1 < \mathit{dQ} < (q - 1)\).
c. \(1 < \mathit{qInv} < p\).
d. \(1 = (\mathit{dP} \times e_{\mathit{pub}}) \bmod (p - 1)\).
e. \(1 = (\mathit{dQ} \times e_{\mathit{pub}}) \bmod (q - 1)\).
f. \(1 = (\mathit{qInv} \times q) \bmod 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.

- The KAS2-Party_V-confirmation scheme in Section 8.3.3.2 can be used to provide assurance to a key-pair owner, acting as party U, that both parties are in possession of the correct private key; i.e., when the key confirmation is successful, party U obtains assurance that party V possesses the private key corresponding to \(\mathit{PubKey}_V\), and that party U possesses the private key corresponding to \(\mathit{PubKey}_U\), where \(\mathit{PubKey}_V\) and \(\mathit{PubKey}_U\) are the public keys associated with parties V and U, respectively, that were used during that KAS2-Party_V-confirmation transaction.

- The KAS2-Party_U-confirmation scheme in Section 8.3.3.3 can be used to provide assurance to a key-pair owner, acting as party V, that both parties are in possession of the correct private key; i.e., when the key confirmation is successful, party V has obtained assurance that party U possesses the private key corresponding to \(\mathit{PubKey}_U\) and that party V possesses the private key corresponding to \(\mathit{PubKey}_V\), where \(\mathit{PubKey}_U\) and \(\mathit{PubKey}_V\) are the public keys associated with parties U and V, respectively, that were used during that KAS2-Party_U-confirmation transaction.

- The KAS2-bilateral-confirmation scheme in Section 8.3.3.4 can be used to provide assurance to a key-pair owner acting as either party U or party V that both parties are in possession of the correct private key; i.e., when the bilateral key-confirmation is successful, each party has obtained assurance that party U possesses the private key corresponding to \(\mathit{PubKey}_U\), and that party V possesses the private key corresponding to \(\mathit{PubKey}_V\), where \(\mathit{PubKey}_U\) and \(\mathit{PubKey}_V\) are the public keys associated with parties U and V, respectively, that were used during that KAS2-bilateral-confirmation transaction.”

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 \(\mathit{PubKey}_V\), (the public key that was associated with party V when that key pair 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 \(\mathit{PubKey}_V\) (the public key that was associated with party V when that key pair 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 \(\mathit{PubKey}_U\) (the public key that was associated with party U when that key pair is used during the key-agreement transaction).

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 correct private key that corresponds to the other party's public key; i.e., when bilateral key-confirmation is successful, party U obtains assurance that party V possesses the private key corresponding to \(\mathit{PubKey}_V\) (the key pair that was associated with party V and that was used during the key-agreement transaction), and party V obtains assurance that party U possesses the private key corresponding to \(\mathit{PubKey}_U\) (the key pair that was associated with party U and that was 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 \(\mathit{PubKey}_V\) (the key pair that was associated with party V and that was used during the key-agreement transaction).

RSAEP produces ciphertext using an RSA public key.
Function call: \(\mathrm{RSAEP}((n, e), m)\)
Input:

1. \((n, e)\): the RSA public key.

2. \(m\): the plaintext; an integer such that \(1 < m < (n - 1)\).

1. If \(m\) does not satisfy \(1 < m < (n - 1)\), output an indication that \(m\) is out of range, and exit without further processing.

2. Let \(c = m^{e} \bmod n\).

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 \(m\), as well as any other potentially sensitive locally stored values used or produced during the execution of the routine. The destruction of these values 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\)).

Function call: \(\mathrm{RSADP}((n, d), c)\) Input:

1. \((n, d)\): the RSA private key.

2. \(c\): the ciphertext; an integer such that \(1 < c < (n - 1)\).

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 \(m = c^{d} \bmod n\).

3. Output \(m\).

Output: \(m\): the plaintext; an integer such that \(1 < m < (n - 1)\), or an error indicator.

Function call: \(\mathrm{RSADP}((p, q, d), c)\) Input:

1. \((p, q, d)\): the RSA private key.

2. \(c\): the ciphertext; an integer such that \(1 < c < (n - 1)\).

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 \(n = p \times q\), the product of \(p\) and \(q\).

3. Let \(m = c^{d} \bmod n\).

4. Output \(m\).

Output: \(m\): the plaintext; an integer such that \(1 < m < (n - 1)\), or an error indicator.

Function call: \(\mathrm{RSADP}(n, e, d, p, q, \mathit{dP}, \mathit{dQ}, \mathit{qInv}, c)\)

1. \((n, e, d, p, q, \mathit{dP}, \mathit{dQ}, \mathit{qInv})\): the RSA private key, where \(\mathit{dP} = d \bmod (p - 1)\), \(\mathit{dQ} = d \bmod (q - 1)\) and \(\mathit{qInv} = q \bmod p\).

2. \(c\): the ciphertext; an integer such that \(1 < c < (n - 1)\).

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. \(m_p = c^{\mathit{dP}} \bmod p\).

3. \(m_q = c^{\mathit{dQ}} \bmod q\).

4. Let \(h = ((m_p - m_q) \times \mathit{qInv}) \bmod p\).

5. Let \(m = (m_q + (q \times h)) \bmod n\).

6. Output \(m\).

RSASVE.GENERATE generates a secret value and corresponding ciphertext using an RSA public key. Function call: \(\mathrm{RSASVE.GENERATE}((n, e))\) Input:

\((n, e)\): an RSA public key. Assumptions: The RSA public key is valid.

1. Compute the value of \(\mathit{nLen} = \lceil \operatorname{len}(n)/8 \rceil\), the byte length of the modulus \(n\).

a. Using the RBG (see Section 5.3), generate \(Z\), a byte string of \(\mathit{nLen}\) bytes.

b. Convert \(Z\) to an integer \(z\) (See Appendix B.2):

c. If \(z\) does not satisfy \(1 < z < (n - 1)\), then go to step 2a.

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\):

b. Convert the ciphertext \(c\) to a ciphertext byte string \(C\) of \(\mathit{nLen}\) bytes (see Appendix B.1):

4. Output the string \(Z\) as the secret value, and the ciphertext \(C\).

Output:

\(Z\): the secret value to be shared (a byte string of \(\mathit{nLen}\) bytes), and \(\mathrm{C}\): the ciphertext (a byte string of \(\mathit{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 the execution of the routine. The destruction of these values 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.

Function call:

\(\mathrm{RSASVE.RECOVER}((n, d), C)\)

Input:

1. \((n, d)\): an RSA private key.

2. \(C\): the ciphertext; a byte string of \(\mathit{nLen}\) bytes.

1. \(\mathit{nLen} = \lceil \operatorname{len}(n)/8 \rceil\), the byte length of \(n\).

If the length of the ciphertext \(C\) is not \(\mathit{nLen}\) bytes in length, output an indication of a decryption error, and exit without further processing.

a. Convert the ciphertext \(C\) to an integer ciphertext \(c\) (see Appendix B.2):

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\):

c. If RSADP indicates that the ciphertext is out of range, output an indication of a decryption error, and exit without further processing.

d. Convert the integer \(z\) to a byte string \(Z\) of \(\mathit{nLen}\) bytes (see Appendix B.1):

4. Output the string \(Z\) as the secret value (i.e., the shared secret), or an error indicator.

\(Z\): the secret value/shared secret (a byte string of \(\mathit{nLen}\) bytes), or an error indicator.

RSA-OAEP consists of asymmetric encryption and decryption operations that are based on an approved hash function, an approved random bit generator, a mask-generation function, and the RSAEP and RSADP primitives. These operations are used by the KTS-OAEP key-transport scheme (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 party’s (i.e., party V’s) 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 \(\mathit{nLen} - 2\mathit{HLen} - 2\) bytes of keying material, where \(\mathit{nLen}\) is the byte length of the recipient’s RSA modulus, and \(\mathit{HLen}\) is the byte length of the values output by the underlying hash function.

1. \(\mathrm{H}\): An approved hash function (see Section 5.1). \(\mathit{HLen}\) is used to denote the byte length of the hash function output.

2. \(\mathrm{MGF}\): The mask-generation function (see Section 7.2.2.2). The MGF employs a hash function \(\mathit{hash}\). This hash function need not be the same as the hash function \(\mathrm{H}\) used in step 3a of Section 7.2.2.3 and step 4a of Section 7.2.2.4.

MGF is a mask-generation function based on an approved hash function (see Section 5.1). The purpose of the MGF is to generate a string of bits that may be used to “mask” other bit strings. The MGF is used by the RSA-OAEP-based schemes specified in Section 9.2.

Let \(\mathit{hash}\) be an approved hash function.

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).

Function call: \(\mathrm{MGF}(\mathit{mgfSeed}, \mathit{maskLen})\)

Auxiliary Function:

\(\mathit{hash}\): an approved hash function (see Section 5.1).

Implementation-Dependent Parameters:

1. \(\mathit{hashLen}\): an integer that indicates the byte length of the output block of the auxiliary hash function, \(\mathit{hash}\).