NIST SP 800-90C 日本語訳

Ideal randomness sources generate identically distributed and independent uniform random bits that provide full-entropy outputs (i.e., one bit of entropy per output bit). Real-world RBGs are designed with a security goal of indistinguishability from the output of an ideal randomness source. That is, given some limits on an adversary’s data and computing power, it is expected that no adversary can reliably distinguish between RBG outputs and outputs from an ideal randomness source.

Consider an adversary that can perform \(2^{w}\) computations (typically, these are guesses of the RBG’s internal state) and is given an output sequence from either an RBG with a security strength of \(s\) bits (where \(s \ge w\)) or an ideal randomness source. It is expected that an adversary has no better probability of determining which source was used for its random bits than

where \(\varepsilon\) is negligible. In this recommendation, the size of the RBG output is limited to \(2^{64}\) output bits and \(\varepsilon \le 2^{-32}\). NIST Internal Report (IR) 8427 [NISTIR_8427] provides a justification for the selection of \(\varepsilon\).

An RBG that has been designed to support a security strength of \(s\) bits is suitable for any application with a targeted security strength that does not exceed \(s\). An RBG that is compliant with this recommendation can support requests for output with a security strength of 128, 192, or 256 bits, except for an RBG3 construction (as described in Sec. 6), which can provide full-entropy output.²

A bitstring with full entropy has an amount of entropy equal to its length. Full entropy bitstrings are important for cryptographic applications, as these bitstrings have ideal randomness properties and may be used for any cryptographic purpose. They may be truncated to any length such that the amount of entropy in the truncated bitstring is equal to its length. However, due to the difficulty of generating and testing full-entropy bitstrings, this recommendation assumes that a bitstring has full entropy if the amount of entropy per bit is at least \(1 - \varepsilon\), where \(\varepsilon\) is at most \(2^{-32}\).

Method 2 (non-physical inclusive): The RBG implementation includes one or more independent, validated non-physical entropy sources; one or more independent, validated physical entropy sources may also be included in the implementation. The entropy from both non-physical entropy sources and (if present) physical entropy sources is counted when fulfilling an entropy request.

Example: Let \(\mathit{pes}_i\) be the \(i^{\text{th}}\) output of a physical entropy source, and let \(\mathit{npes}_j\) be the \(j^{\text{th}}\) output of a non-physical entropy source. If an implementation consists of one physical and one non-physical entropy source, and a request has been made for 128 bits of entropy, the concatenated bitstring might be something like:

According to Method 1, only the entropy in \(\mathit{pes}_1\), \(\mathit{pes}_2\), ..., \(\mathit{pes}_n\) would be counted toward fulfilling the 128-bit entropy request. Any entropy in \(\mathit{npes}_1\), ..., \(\mathit{npes}_m\) is not counted, even though it may be used.

According to Method 2, all of the entropy in \(\mathit{pes}_1\), \(\mathit{pes}_2\), ..., \(\mathit{pes}_n\) and in \(\mathit{npes}_1\), \(\mathit{npes}_2\), ..., \(\mathit{npes}_m\) is counted.

In order to reseed a DRBG at a security strength of \(s\) bits, new seed material is provided to the DRBG from either an entropy source or an RBG. If the seed material is provided by an entropy source, it must contain at least \(s\) bits of min-entropy. If the seed material is provided by an RBG, the RBG must support a security strength of at least \(s\) bits, and the seed material must be at least \(s\) bits long. Seed material from an entropy source will always be unpredictable; seed material from an RBG will be unpredictable if that RBG has not been compromised.

A DRBG output is said to have prediction resistance when the DRBG is reseeded with at least \(s\) bits of min-entropy immediately before the output is generated by the DRBG. The entropy for this reseeding process needs to be provided by either an entropy source or an RBG3 construction for prediction resistance to be provided.

Although reseeding provides fresh randomness that is incorporated into an already instantiated DRBG at a security strength of \(s\) bits, the reseed process does not increase the DRBG’s security strength. For example, a reseed of a DRBG that has been instantiated to support a security strength of 128 bits does not increase the DRBG’s security strength to 256 bits when reseeding with 128 bits of fresh entropy.

3. An entropy source or DRBG is assumed to output no more than \(2^{64}\) bits. In the case of an RBG1 construction with one or more subordinate DRBGs, the output limit applies to the total output provided by the RBG1 construction and its subordinate DRBGs.

4. Each entropy-source output is assumed to have a fixed length \(\mathit{ES\_len}\) (in bits).

5. Each entropy-source output is assumed to contain at least a known amount of entropy, denoted as \(\mathit{ES\_entropy}\), that was assessed during entropy-source implementation validation. See [SP_800-90B] for entropy estimation.

7. The outputs from a single entropy source can be concatenated. The entropy of the resultant bitstring is the sum of the entropy from each entropy-source output. For example, if \(m\) outputs are concatenated, then the length of the bitstring is \(m \times \mathit{ES\_len}\) bits, and the entropy for that bitstring is assumed to be \(m \times \mathit{ES\_entropy}\) bits. This is a consequence of the model of entropy used in [SP_800-90B].

8. The output of multiple independent entropy sources can be concatenated in an RBG. The entropy in the resultant bitstring is the sum of the entropy in each independent entropy-source output that is contributing to the entropy in the bitstring (see Methods 1 and 2 in Sec. 2.3). For example, suppose that the outputs from independent physical entropy sources A and B and non-physical entropy source C are concatenated. The length of the concatenated bitstring is the sum of the lengths of the component bitstrings (e.g., \(\mathit{ES\_len}_A + \mathit{ES\_len}_B + \mathit{ES\_len}_C\)).

• Using Method 1 (physical only) in Sec. 2.3, the amount of entropy in the concatenated bitstring is \(\mathit{ES\_entropy}_A + \mathit{ES\_entropy}_B\).

• Using Method 2 (non-physical inclusive) in Sec. 2.3, the amount of entropy in the concatenated bitstring is the sum of all entropy in the bitstrings (i.e., \(\mathit{ES\_entropy}_A + \mathit{ES\_entropy}_B + \mathit{ES\_entropy}_C\)).

• If the entropy source provides the requested amount of entropy, a \(\mathit{status}\) indication of success is returned along with a bitstring that contains the requested amount of entropy.

• If the entropy source detects a failure of the primary noise source (e.g., an error from which it cannot recover), the entropy source returns a \(\mathit{status}\) indicating a failure. Other output is not provided.

• If the entropy source indicates an error other than failure (e.g., entropy cannot be obtained in a timely manner, or there is an intermittent problem), the entropy source returns a \(\mathit{status}\) indicating that the entropy source cannot provide output at this time. Other output is not provided.

11. Full entropy bits can be extracted from the output of a DRBG specified in [SP_800-90A] (e.g., a hash function or block cipher) when the amount of fresh entropy inserted into the algorithm exceeds the number of bits that are extracted by at least 64 bits. In particular, for a DRBG that has been instantiated at a security strength of \(s\) bits, \(s\) full-entropy bits can be extracted from the output of that DRBG when at least \(s + 64\) bits of fresh entropy are inserted into the DRBG immediately before the output is generated (see [NISTIR_8427] for details).

Instantiating a DRBG with security strength \(s\) from an entropy source (e.g., the entropy source for the DRBG in an RBG2 or RBG3 construction or the initial randomness source for the DRBG in a root RBGC construction) requires at least \(3s/2\) bits of min-entropy.⁶ Instantiating a DRBG from another RBG (e.g., the DRBG in an RBG1, RBG1 sub-DRBG, or any non-root RBGC construction) requires at least \(3s/2\) bits of seed material and requires that the DRBG providing the seed material supports at least an \(s\)-bit security strength.

Fig. 4. \(\mathbf{DRBG\_Instantiate}\) function

The \(\mathbf{DRBG\_Instantiate}\) function (shown in Fig. 4) is used to instantiate a DRBG at the \(\mathit{requested\_instantiation\_security\_strength}\) using the output of a randomness source⁷ and an optional but strongly recommended \(\mathit{personalization\_string}\) to create a seed (see Sec. 2.4.1). Details about the \(\mathbf{DRBG\_Instantiate}\) function are provided in [SP_800-90A].

If the \(\mathit{status}\) code returned for the \(\mathbf{DRBG\_Instantiate}\) function indicates a success (i.e., the DRBG has been instantiated at the requested security strength), a state handle may⁸ be returned to indicate the particular DRBG instance (e.g., pointing to the internal state to be used by this instance). When provided by the \(\mathbf{DRBG\_Instantiate}\) function, the state handle is used in subsequent calls to the DRBG (e.g., during a \(\mathbf{DRBG\_Generate}\) call) to reference the internal state information for the instantiation. The information in the internal state includes the security strength of the instantiation and other information that changes during DRBG execution (see [SP_800-90A] for each DRBG design).

When the DRBG has been instantiated at the requested security strength, the DRBG will operate at that security strength even if the security strength requested in subsequent \(\mathbf{DRBG\_Generate}\) calls (see Sec. 2.8.1.2) is less than the instantiated security strength. For example, if a DRBG has been instantiated at a security strength of 256 bits, all output will be generated at that strength even when a request is received to generate bits at a strength of 128 bits.

If the \(\mathit{status}\) code indicates an error and an implementation is designed to return a state handle, an invalid state handle (e.g., \(\mathit{Null}\)) is returned.

The \(\mathbf{DRBG\_Instantiate}\) function is requested by an application using a \(\mathbf{DRBG\_Instantiate\_request}\):

As shown in Fig. 5, a \(\mathbf{DRBG\_Instantiate\_request}\) received by a DRBG results in the execution of the DRBG’s instantiate function, providing the input parameters for that function. The \(\mathbf{DRBG\_Instantiate}\) function within the DRBG then obtains \(\mathit{seed\_material}\) from the randomness sources, instantiates a DRBG, and returns the \(\mathit{status}\) of the process and (if there is no error) a \(\mathit{state\_handle}\) for the internal state to the application.

Fig. 6. \(\mathbf{DRBG\_Generate}\) function

The \(\mathbf{DRBG\_Generate}\) function (shown in Fig. 6) is used to generate a specified number of bits. If a suitable \(\mathit{state\_handle}\) is provided during instantiation, it is included as input to indicate the DRBG instance to be used. The number of bits to be returned and the security strength that the DRBG needs to support for generating the bitstring are provided with (optional) additional input. As stated in Sec. 2.4.1, the ability to accept additional input is recommended.

The \(\mathbf{DRBG\_Generate}\) function returns status information — either an indication of success or an error. If the returned status code indicates a success, the generated bits are returned.

• If \(\mathit{requested\_number\_of\_bits}\) is equal to or greater than the instantiated security strength, the security strength that the \(\mathit{returned\_bits}\) can support (if used as a key) is:

• If the \(\mathit{requested\_number\ of\ bits}\) is less than the instantiated security strength, and the \(\mathit{returned\_bits}\) are to be used as a key, the key is capable of supporting a security strength of:

If the status code indicates an error, the \(\mathit{returned\_bits}\) consists of a \(\mathit{Null}\) bitstring. An example of a condition in which an error indication may be returned is a request for a security strength that exceeds the instantiated security strength for the DRBG.

Details about the \(\mathbf{DRBG\_Generate}\) function are provided in [SP_800-90A].

The \(\mathbf{DRBG\_Generate}\) function is requested by an application using a \(\mathbf{DRBG\_Generate\_request}\):

As shown in Fig. 7, a \(\mathbf{DRBG\_Generate\_request}\) received by a DRBG results in the execution of the DRBG’s \(\mathbf{DRBG\_Generate}\) function, providing the input parameters for that function. The \(\mathbf{DRBG\_Generate}\) function generates the requested number of bits and returns the \(\mathit{status}\) of the process and (if there is no error) the newly generated bits.

Fig. 8. \(\mathbf{DRBG\_Reseed}\) function

A \(\mathbf{DRBG\_Reseed}\) function (shown in Fig. 8) is used to acquire at least \(s\) bits of fresh randomness for the DRBG instance indicated by the state handle (or the only instance if no state handle has been provided), where \(s\) is the security strength of the DRBG to be reseeded.¹⁰ In addition to the seed material provided from the DRBG’s randomness sources during reseeding, optional \(\mathit{additional\_input}\) may be incorporated into the reseed process. As discussed in Sec. 2.4.1, the capability for handling and using additional input is recommended. Details about the \(\mathbf{DRBG\_Reseed}\) function are provided in [SP_800-90A].

An indication of the \(\mathit{status}\) is returned.

The \(\mathbf{DRBG\_Reseed}\) function is requested by an application using a \(\mathbf{DRBG\_Reseed\_request}\):

As shown in Fig. 9, a \(\mathbf{DRBG\_Reseed\_request}\) received by a DRBG results in the execution of the DRBG’s \(\mathbf{DRBG\_Reseed}\) function, providing the input parameters for that function. The \(\mathbf{DRBG\_Reseed}\) function then obtains \(\mathit{seed\_material}\) from a randomness source, reseeds the DRBG instantiation, and returns the \(\mathit{status}\) of the process to the application.

¹⁰ The value of \(s\) may be available in the DRBG’s internal state [SP_800-90A].

A single entropy source request may not be sufficient to obtain the entropy required for seeding and reseeding a DRBG or for providing input for the exclusive-or operation in an RBG3(XOR) construction (see Sec. 6.4.1). SP 800-90C uses the term \(\mathbf{Get\_entropy\_bitstring}\) to identify the process of obtaining the required entropy from one or more entropy sources. For convenience in describing the RBG constructions, this process is represented as a function whose input includes an indication of the amount of entropy that is needed from the entropy sources and whose output includes a status report on the success or failure of the process. If the process is successful, a bitstring containing the requested entropy is produced (see Fig. 10). The \(\mathbf{Get\_entropy\_bitstring}\) function is invoked herein as:

where \(\mathit{bits\_of\_entropy}\) is the amount of entropy requested for return in the \(\mathit{entropy\_bitstring}\), \(\mathit{counting\_method}\) is the method to be used for counting entropy in the entropy sources (see Sec. 2.3), \(\mathit{entropy\_source\_ID}\) is an optional parameter that indicates the specific entropy source to be used, and \(\mathit{status}\) indicates whether the request has been satisfied.

Fig. 10. \(\mathbf{Get\_entropy\_bitstring}\) function

The \(\mathbf{Get\_entropy\_bitstring}\) process requests entropy from any available validated entropy sources or the entropy source identified by \(\mathit{entropy\_source\_ID}\) (if present). Acquiring entropy from non-validated entropy sources is handled separately (e.g., by a different process) to avoid misuse. See Sec. 3.1 for additional discussion about the \(\mathbf{Get\_entropy\_bitstring}\) process.

The instantiate function of the RBG3 construction (shown in Fig. 11) will result in the execution of the DRBG’s instantiate function (provided in Sec. 2.8.1.1). A \(\mathit{requested\_security\_strength}\) may optionally be provided as an input parameter to indicate the minimum security strength to be supported by the DRBG within the RBG3 construction. An optional but recommended \(\mathit{personalization\_string}\) (see Sec. 2.4.1) may be provided as an input parameter. If included as input to the RBG3 instantiation function, the \(\mathit{personalization\_string}\) is passed to the DRBG that is instantiated by the instantiate function (see Sec. 6.4.1.1 and 6.5.1.1).

If the returned status code indicates a success, a state handle may be returned to indicate the DRBG instance that is to be used by the construction (e.g., the state handle points to the internal state used by this instance of the DRBG within the RBG3 construction). If multiple instances of the DRBG are used (in addition to the DRBG instance used by the RBG3 construction), a separate state handle is returned for each instance. When provided, the state handle is used in subsequent calls to that RBG (e.g., during a call to the RBG3 generate function; see Sec. 2.8.3.2) or when accessing the DRBG directly (e.g., during a reseed of the DRBG; see Sec. 6.4.1.4). If the status code indicates an error (e.g., entropy is not currently available or the entropy source has failed), an invalid (e.g., \(\mathit{Null}\)) state handle is returned.

The instantiation of the DRBG within an RBG3(XOR) or RBG3(RS) construction is requested by an application using an \(\mathbf{Instantiate\_RBG3\_DRBG\_request}\):

Both the \(\mathit{requested\_security\_strength}\) and a \(\mathit{personalization\_string}\) are optional in the \(\mathbf{Instantiate\_RBG3\_DRBG\_request}\). An \(\mathbf{Instantiate\_RBG3\_DRBG\_request}\) received by an RBG3 construction results in the execution of the DRBG’s instantiate function, as shown in Fig. 12.

If no error is detected in the request, the \(\mathbf{Instantiate\_RBG3\_DRBG}\) function obtains \(\mathit{seed\_material}\) from the entropy source(s), instantiates the DRBG, and returns the \(\mathit{status}\) of the process and (possibly) a \(\mathit{state\_handle}\) for the internal state to the application.

In the case of the RBG3 construction, the (optional) \(\mathit{requested\_security\_strength}\) parameter in the \(\mathbf{Instantiate\_RBG3\_DRBG\_request}\) should be interpreted as the minimum security strength that is required by the consuming application if entropy-source failures are undetected. Therefore, if the \(\mathit{requested\_security\_strength}\) parameter is provided as input, it is compared to the value of the highest security strength that can be supported by the DRBG. If the \(\mathit{requested\_security\_strength}\) exceeds the security strength that can be supported by the DRBG, then an error indication is returned as the \(\mathit{status}\) in response to the \(\mathbf{Instantiate\_RBG3\_DRBG\_request}\).

If no error is detected in the request, the \(\mathbf{Instantiate\_RBG3\_DRBG}\) function obtains \(\mathit{seed\_material}\) from the entropy sources, instantiates the DRBG, and returns the \(\mathit{status}\) of the process and (possibly) a \(\mathit{state\_handle}\) for the internal state to the application.

The RBG3(XOR) and RBG3(RS) generate function calls are essentially the same, but the function designs are very different (see Sec. 6.4 for the \(\mathbf{RBG3(XOR)\_Generate}\) function and Sec. 6.5 for the \(\mathbf{RBG3(RS)\_Generate}\) function):

The RBG3 generate functions are requested to use the DRBG indicated by the \(\mathit{state\_handle}\) to generate the \(\mathit{requested\_number\_of\_bits}\) using any (optional) \(\mathit{additional\_input}\) provided. If the returned \(\mathit{status}\) code from the \(\mathbf{RBG3(XOR)\_Generate}\) or \(\mathbf{RBG3(RS)\_Generate}\) function indicates a success, a bitstring that contains the newly generated bits is also returned. If the status code indicates an error (e.g., the entropy source has failed), a \(\mathit{Null}\) bitstring is returned as the \(\mathit{returned\_bits}\).

If a suitable \(\mathit{state\_handle}\) was provided during instantiation (e.g., returned in response to an \(\mathbf{Instantiate\_RBG3\_DRBG\_request}\) within an RBG3 instantiate function; see Sec. 2.8.3.1), it is included in the \(\mathbf{RBG3\_Generate\_request}\).

As shown in Fig. 14, an RBG3 generate request received by an RBG3 construction results in the execution of the RBG’s generate function, providing the input parameters for that function. The entropy source is accessed, the requested number of bits are generated, and the \(\mathit{status}\) of the process and the newly generated bits are returned to the application. The RBG3 generate process for the RBG3(XOR) and RBG3(RS) construction are provided in Sec. 6.4 and 6.5, respectively.

4. If a failure is reported during the \(\mathbf{Get\_entropy\_bitstring}\) process by any physical or non-physical entropy source whose entropy is counted toward fulfilling an entropy request, the \(\mathbf{Get\_entropy\_bitstring}\) process shall behave as follows:¹¹

Since this conditioning is performed outside of an entropy source, the output is said to be externally conditioned. The conditioning function operates on a bitstring that is produced by the \(\mathbf{Get\_entropy\_bitstring}\) process to produce an \(\mathit{entropy\_bitstring}\). Reasons to perform conditioning might include:

• Reducing the bias in the \(\mathit{entropy\_bitstring}\),

• Distributing entropy uniformly across the \(\mathit{entropy\_bitstring}\),

• Reducing the length of the \(\mathit{entropy\_bitstring}\) and compressing the entropy into a smaller bitstring, and/or

The conditioning functions operate on bitstrings that are obtained using the \(\mathbf{Get\_entropy\_bitstring}\) process (see Section 3.1) to obtain an \(\mathit{entropy\_bitstring}\) from one or more entropy sources.

where the \(\mathit{input\_parameters}\) for the selected conditioning function are discussed in Sec. 3.2.1.2 and 3.2.1.3, and \(\mathit{conditioned\_output\_block}\) is the output returned by the conditioning function. The length of the \(\mathit{conditioned\_output\_block}\) is the length of the output block of the conditioning function used and indicated as \(\mathit{output\_len}\) in subsequent sections.

The \(\mathbf{HMAC}\), \(\mathbf{CMAC}\), and \(\mathbf{CBC\text{-}MAC}\) vetted conditioning functions require the input of a \(\mathit{Key}\) of a specific length (\(\mathit{keylen}\)), depending on the conditioning function and its primitive. Unlike other cryptographic applications, keys used in these external conditioning functions do not require secrecy to accomplish their purpose, so they may be hard-coded, fixed, or all zeros.

For the \(\mathbf{CMAC}\) and \(\mathbf{CBC\text{-}MAC}\) conditioning functions, the length of the key shall be an approved key length for the block cipher used (e.g., \(\mathit{keylen} = 128\), 192, or 256 bits for AES).

For the \(\mathbf{HMAC}\) conditioning function, the length of the key shall be equal to the length of the hash function’s output (i.e., \(\mathit{output\_len}\)).

where the hash function operates on the \(\mathit{entropy\_bitstring}\) provided as input.

2. Using \(\mathrm{HMAC}\) (as specified in [SP_800_224]) with an approved hash function:

where \(\mathrm{HMAC}\) operates on the \(\mathit{entropy\_bitstring}\) using a \(\mathit{Key}\) that is determined as specified in Sec. 3.2.1.1.

In both cases, the length of the conditioned output is equal to the length of the output block of the selected hash function (i.e., \(\mathit{output\_len}\)).

3. Using \(\mathbf{Hash\_df}\), as specified in SP 800-90A:

where the derivation function operates on the \(\mathit{entropy\_bitstring}\) provided as input to produce a bitstring of \(\mathit{output\_len}\) bits.

1. Using \(\mathrm{CMAC}\) (as specified in [SP_800-38B]) with an approved block cipher:

where \(\mathrm{CMAC}\) operates on the \(\mathit{entropy\_bitstring}\) using a \(\mathit{Key}\) that is determined as specified in Sec. 3.2.1.1.

2. Using \(\mathrm{CBC\text{-}MAC}\) (specified in [SP_800-90B]) with an approved block cipher:

where \(\mathrm{CBC\text{-}MAC}\) operates on the \(\mathit{entropy\_bitstring}\) using a \(\mathit{Key}\) that is determined as specified in Sec. 3.2.1.1.

\(\mathrm{CBC\text{-}MAC}\) shall only be used as an external conditioning function under the following conditions:

1. The length of the input is an integer that is a multiple of the size of the block cipher (e.g., a multiple of 128 bits for AES). No padding is done by \(\mathrm{CBC\text{-}MAC}\) itself.¹²

2. If the \(\mathrm{CBC\text{-}MAC}\) conditioning function is used for the external conditioning of an entropy source output for \(\mathrm{CTR\_DRBG}\) instantiation or reseeding:

3. Using the \(\mathbf{Block\_cipher\_df}\) as specified in [SP_800-90A] with an approved block cipher:

where \(\mathbf{Block\_cipher\_df}\) operates on the \(\mathit{entropy\_bitstring}\) using a key that is specified within the function, and the \(\mathit{block\_length}\) is defined for the block cipher (e.g., 128 for AES).

The \(\mathbf{Get\_conditioned\_input}\) procedure specified below iteratively requests entropy from the \(\mathbf{Get\_entropy\_bitstring}\) process (represented as a \(\mathbf{Get\_entropy\_bitstring}\) procedure; see Sec. 2.8.2 and 3.1) and distributes the entropy in the newly acquired \(\mathit{entropy\_bitstring}\) across the conditioning function’s output block. The output of the \(\mathbf{Get\_conditioned\_input}\) procedure is the concatenation of the conditioning function output blocks. The entire output of the

¹² Any padding required could be done before submitting the \(\mathit{entropy\_bitstring}\) to the CBC-MAC function.

\(\mathbf{Get\_conditioned\_input}\) procedure shall be provided as input to the DRBG mechanism (i.e., the output of the \(\mathbf{Get\_conditioned\_input}\) function shall not be truncated).

Let \(\mathit{output\_len}\) be the length of the conditioning function’s output block.

\(\mathbf{Get\_conditioned\_input}\):

1. \(n\): The amount of entropy to be obtained.

2. \(\mathit{counting\_method}\): The counting method to be used (i.e., either Method 1¹³ or Method 2,¹⁴ as described in Sec. 2.3).

3. \(\mathit{target\_entropy\_source}\): An optional parameter that indicates the specific entropy source to be queried. If the \(\mathit{target\_entropy\_source}\) is not indicated, output is to be obtained from any validated entropy sources producing output that have not reported a failure.

1. \(\mathit{status}\): The status returned from the \(\mathbf{Get\_conditioned\_input}\) process.

2. \(\mathit{Conditioned\_entropy\_bitstring}\): A bitstring containing conditioned entropy or the \(\mathit{Null}\) string.

1. \(v = \lceil n/\mathit{output\_len} \rceil\).

2. \(w = \lceil n/v \rceil\).

3. \(\mathit{Conditioned\_entropy\_bitstring}\) = the \(\mathit{Null}\) string.

4. For \(i = 1, \ldots, v\)

4.1 \((\mathit{status}, \mathit{entropy\_bitstring}) = \mathbf{Get\_entropy\_bitstring}(w, \mathit{counting\_method}, \mathit{target\_entropy\_source})\).

4.2 If \((\mathit{status} \ne \mathrm{SUCCESS})\), then return \((\mathit{status}, \mathit{Null})\).

4.3 \(\mathit{conditioned\_output\_block} = \mathbf{Conditioning\_function}(\mathit{input\_parameters})\).

4.4 \(\mathit{Conditioned\_entropy\_bitstring} = \mathit{Conditioned\_entropy\_bitstring} \parallel \mathit{conditioned\_output\_block}\).

5. Return \((\mathrm{SUCCESS}, \mathit{Conditioned\_entropy\_bitstring})\).

Step 1 determines the number of output blocks (\(v\)) required to hold the requested amount of entropy.

Step 2 determines the amount of entropy (\(w\)) that will be requested for each of the \(v\) output blocks.

Step 3 sets the bitstring into which conditioned output will be collected (i.e., \(\mathit{Conditioned\_entropy\_bitstring}\)) to the \(\mathit{Null}\) string.

Step 4 is iterated \(v\) times to obtain and condition the requested amount of entropy for each output block of the conditioning function.

• Step 4.1 requests \(w\) bits of entropy from the entropy sources using the \(\mathbf{Get\_entropy\_bitstring}\) call (see Sec. 2.8.2 and 3.1) and indicates the method to be used for counting entropy (i.e., Method 1¹⁵ or Method 2¹⁶ in Sec. 2.3) and (if provided as input) the only entropy source to be used (indicated by the \(\mathit{target\_entropy\_source}\) input parameter).

• Step 4.2 checks whether the \(\mathit{status}\) returned in step 4.1 indicated a success. If the \(\mathit{status}\) did not indicate a success, the \(\mathit{status}\) is returned with a \(\mathit{Null}\) string as the \(\mathit{Conditioned\_entropy\_bitstring}\).

• Step 4.3 invokes the conditioning function for processing the \(\mathit{entropy\_bitstring}\) obtained from step 4.1 to distribute the entropy throughout the conditioning function’s output block. The \(\mathit{input\_parameters}\) for the selected \(\mathbf{Conditioning\_function}\) are specified in Sec. 3.2.1.2 and 3.2.1.3 or at [SP800_90WebSite], depending on the conditioning function used.

• Step 4.4 concatenates the \(\mathit{conditioned\_output\_block}\) from step 4.3 to the \(\mathit{Conditioned\_entropy\_bitstring}\).

• If all of the requested entropy has not been obtained and conditioned, then go to step 4.1 with an updated value of \(v\).

Step 5 returns a \(\mathit{status}\) of SUCCESS and the value of \(\mathit{Conditioned\_entropy\_bitstring}\).

The \(\mathbf{Get\_conditioned\_full\_entropy\_input}\) procedure specified below produces a bitstring with full entropy using a vetted conditioning function whenever a bitstring with full entropy is required. This process is unnecessary if full-entropy output is provided by the entropy sources.

The approach used by this procedure is to acquire sufficient entropy from the entropy sources to iteratively produce \(\mathit{output\_len}\) bits with full entropy in the conditioning function’s output block, where \(\mathit{output\_len}\) is the length of the output block. The amount of entropy required for each use of the conditioning function is \(\mathit{output\_len} + 64\) bits (see item 11 in Sec. 2.6). This process is repeated until the requested number of full-entropy bits has been produced.

The \(\mathbf{Get\_conditioned\_full\_entropy\_input}\) procedure obtains entropy from either 1) a designated entropy source (if a specific entropy source is identified as the \(\mathit{target\_entropy\_source}\)) or 2) any available entropy source using the \(\mathbf{Get\_entropy\_bitstring}\) process (represented as a \(\mathbf{Get\_entropy\_bitstring}\) procedure; see Sec. 2.8.2 and 3.1) and conditions the newly acquired \(\mathit{entropy\_bitstring}\) to provide an \(n\)-bit string with full entropy.

\(\mathbf{Get\_conditioned\_full\_entropy\_input}\):

1. \(n\): The amount of entropy to be obtained.

2. \(\mathit{counting\_method}\): The counting method to be used (i.e., either Method 1 or Method 2, as described in Sec. 2.3).

3. \(\mathit{target\_entropy\_source}\): An optional parameter that indicates the specific entropy source to be queried. If the \(\mathit{target\_entropy\_source}\) is not indicated, output is to be obtained from any validated entropy source producing output that has not reported a failure.

1. \(\mathit{status}\): The status returned from the \(\mathbf{Get\_conditioned\_full\_entropy\_input}\) process.

2. \(\mathit{Full\_entropy\_bitstring}\): An \(n\)-bit string with full entropy or the \(\mathit{Null}\) string.

1. \(\mathit{temp} = \text{the } \mathit{Null} \text{ string}\).

2. \(\mathit{ctr} = 0\).

3. While \(\mathit{ctr} < n\), do

3.1 \((\mathit{status}, \mathit{entropy\_bitstring}) = \mathbf{Get\_entropy\_bitstring}(\mathit{output\_len} + 64, \mathit{counting\_method}, \mathit{target\_entropy\_source})\).

3.2 If (\(\mathit{status} \ne \mathrm{SUCCESS}\)), then return \((\mathit{status}, \mathit{Null})\).

3.3 \(\mathit{conditioned\_output\_block} = \mathbf{Conditioning\_function}(\mathit{input\_parameters})\).

3.4 \(\mathit{temp} = \mathit{temp} \parallel \mathit{conditioned\_output\_block}\).

3.5 \(\mathit{ctr} = \mathit{ctr} + \mathit{output\_len}\).

4. \(\mathit{Full\_entropy\_bitstring} = \mathbf{leftmost}(\mathit{temp}, n)\).

5. Return \((\mathrm{SUCCESS}, \mathit{Full\_entropy\_bitstring})\).

Steps 1 and 2 initialize the temporary bitstring (\(\mathit{temp}\)) for storing the full-entropy bitstring being assembled and the counter (\(\mathit{ctr}\)) that counts the number of full-entropy bits produced.

• Step 3.1 requests \(\mathit{output\_len} + 64\) bits of entropy from the validated entropy sources using the indicated method (i.e., Method 1 or Method 2) for counting entropy and (if present)

using only the entropy source identified as the \(\mathit{target\_entropy\_source}\). If the entropy source to be used is not identified, the entropy is to be obtained from all available entropy sources that have not reported a failure.

• Step 3.2 checks whether the \(\mathit{status}\) returned in step 3.1 indicated a success. If the \(\mathit{status}\) did not indicate a success, the \(\mathit{status}\) is returned along with a \(\mathit{Null}\) bitstring as the \(\mathit{Full\_entropy\_bitstring}\).

• Step 3.3 invokes the conditioning function for processing the \(\mathit{entropy\_bitstring}\) obtained from step 3.1. The \(\mathit{input\_parameters}\) for the selected \(\mathbf{Conditioning\_function}\) are specified in Sec. 3.2.1.2 or 3.2.1.3 or at [SP800_90WebSite], depending on the conditioning function used.

• Step 3.4 concatenates the \(\mathit{conditioned\_output\_block}\) received in step 3.3 to the temporary bitstring (\(\mathit{temp}\)).

• If less than \(n\) full-entropy bits have been produced, repeat the process starting at step 3.1.

Step 4 truncates the full-entropy bitstring to \(n\) bits.

• Step 5 returns an \(n\)-bit full-entropy bitstring as the \(\mathit{Full\_entropy\_bitstring}\).

As shown in Fig. 15, an RBG1 construction consists of a DRBG contained within a DRBG security boundary in one cryptographic module and an RBG (serving as a randomness source) contained within a separate cryptographic module from that of the RBG1 construction. For convenience and clarity, the DRBG within the RBG1 construction will sometimes be referred to as \(\mathrm{DRBG}_1\). The required health tests are not shown in the figure.

The RBG for instantiating \(\mathrm{DRBG}_1\) must be either 1) an RBG2(P) construction that supports a reseed request from the RBG1 construction (see Sec. 5), 2) an RBG3 construction (see Sec. 6), or 3) the root of a tree of RBGC constructions with an RBG3 construction or a physical full-entropy source as the initial randomness source (see Sec. 7). The root is immediately reseeded before generating the seed material. A physically secure channel between the randomness source and \(\mathrm{DRBG}_1\) is used to securely transport the seed material required for DRBG instantiation. An optional recommended personalization string and optional additional input may be provided from within the DRBG’s cryptographic module or from outside of that module (see Sec. 2.4.1).

The DRBG within the RBG1 construction (\(\mathrm{DRBG}_1\)) may be instantiated by an application at any security strength possible for the DRBG design using the \(\mathbf{DRBG\_Instantiate\_request}\) discussed in Sec. 2.8.1.1:

The \(\mathbf{DRBG\_Instantiate\_request}\) received by \(\mathrm{DRBG}_1\) from an application shall result in the execution of the \(\mathbf{DRBG\_Instantiate}\) function within \(\mathrm{DRBG}_1\) (see Sec. 2.8.1.1):

The \(\mathit{status}\) returned by the \(\mathbf{DRBG\_Instantiate}\) function shall be returned to the requesting application in response to the \(\mathbf{DRBG\_Instantiate\_request}\). \(\mathit{RBG1\_DRBG1\_state\_handle}\) is the state handle for \(\mathrm{DRBG}_1\)’s internal state; the state handle may be \(\mathit{Null}\).

The \(\mathbf{DRBG\_Instantiate}\) function within \(\mathrm{DRBG}_1\) shall use an external RBG (i.e., the randomness source) to obtain the \(\mathit{seed\_material}\) necessary for establishing the DRBG’s security strength.

In SP 800-90A, the \(\mathbf{DRBG\_Instantiate}\) function specifies the use of a \(\mathbf{Get\_randomness\_source\_input}\) call to obtain seed material from the randomness source for instantiation (see Sec. 2.8.1.4 in this document and [SP_800-90A]). For an RBG1 construction, an approved external RBG2(P), RBG3, or root RBGC construction must be used as the randomness source (see Sec. 5, 6, and 7, respectively).

If the randomness source is an RBG2(P) construction (see Fig. 16), the RBG2(P) construction must be reseeded using its internal entropy source(s) before generating bits to be provided to \(\mathrm{DRBG}_1\). The \(\mathbf{Get\_randomness\_source\_input}\) call in the \(\mathbf{DRBG\_Instantiate}\) function of \(\mathrm{DRBG}_1\) shall be replaced by a reseed request followed by a generate request to the RBG2(P) construction that is serving as the randomness source (see steps 1a and 2a below).

If the randomness source is an RBG3 construction (as shown in Fig. 17), the \(\mathbf{Get\_randomness\_source\_input}\) call in the \(\mathbf{DRBG\_Instantiate}\) function of \(\mathrm{DRBG}_1\) shall be replaced by the appropriate call to the RBG3 generate function (see Sec. 2.8.3.2, 6.4.1.2, and 6.5.1.2 and steps 1b and 2b below).

If the randomness source for RBG1 is the root of a tree of RBGC constructions (see Fig. 18), its initial randomness source must be an RBG3 construction or a physical full-entropy source (see Sec. 7) that is used to reseed the root before the root generates seed material for the RBG1 construction. The \(\mathbf{Get\_randomness\_source\_input}\) call in the \(\mathbf{DRBG\_Instantiate}\) function of \(\mathrm{DRBG}_1\) shall be replaced by a reseed request and a generate request that is sent to the root RBGC construction (see Sec. 7.2.1.2).

Let \(\mathrm{DRBG}_1\) be the DRBG to be instantiated within the RBG1 construction, and let \(\mathrm{DRBG}_R\) be the DRBG used within the randomness source (i.e., an RBG2(P), RBG3, or RBGC construction). Let \(s\) be the security strength to be instantiated for \(\mathrm{DRBG}_1\). \(\mathbf{DRBG\_Reseed\_request}\) and \(\mathbf{DRBG\_Generate\_request}\) are used by an application to request the generation and reseed of the DRBG within the randomness source (i.e., \(\mathrm{DRBG}_R\)). Let \(\mathit{DRBG_{R}\_state\_handle}\) be the state handle for \(\mathrm{DRBG}_R\). Let \(\mathit{keylen}\) be the length of the key used by the cryptographic primitive, and let \(\mathit{output\_len}\) be the length of the cryptographic primitive’s output block.

Upon receiving the instantiation request from the application, \(\mathrm{DRBG}_1\) is instantiated as follows:

1. When an RBG1 construction is instantiating a \(\mathrm{CTR\_DRBG}\) without a derivation function, \(\mathit{keylen} + \mathit{output\_len}\) bits shall be obtained from the randomness source as follows:

a. If the randomness source is an RBG2(P) or root RBGC construction (see Fig. 16 and Fig. 18, respectively), the \(\mathbf{Get\_randomness\_source\_input}\) call in the \(\mathbf{DRBG\_Instantiate}\) function of \(\mathrm{DRBG}_1\) is replaced by a request to reseed \(\mathrm{DRBG}_R\) (i.e., the DRBG within the RBG2(P) or root RBGC construction) and followed by a request to generate bits:

• \(\mathit{status} = \mathbf{DRBG\_Reseed\_request}(\mathit{DRBG_{R}\_state\_handle}, \mathit{additional\_input})\).

• If \((\mathit{status} \ne \mathrm{SUCCESS})\), then return \((\mathit{status}, \mathit{Invalid\_state\_handle})\).

• \((\mathit{status}, \mathit{seed\_material}) = \mathbf{DRBG\_Generate\_request}(\mathit{DRBG_{R}\_state\_handle}, \mathit{keylen} + \mathit{output\_len}, s, \mathit{additional\_input})\).

• If (\(\mathit{status} \ne \mathrm{SUCCESS}\)), then return (\(\mathit{status}, \mathit{Invalid\_state\_handle}\)).

\(\mathbf{DRBG\_Reseed\_request}\) and \(\mathbf{DRBG\_Generate\_request}\) are used here to indicate requests for the DRBG within the randomness source (\(\mathrm{DRBG}_{\mathrm{R}}\)) to execute the \(\mathbf{DRBG\_Reseed}\) function and \(\mathbf{DRBG\_Generate}\) function within \(\mathrm{DRBG}_{\mathrm{R}}\) (see Sec. 2.8.1.3, and 2.8.1.2, respectively).¹⁷

b. If the randomness source is an RBG3(XOR) or RBG3(RS) construction (see Fig. 17), the \(\mathbf{Get\_randomness\_source\_input}\) call in the \(\mathbf{DRBG\_Instantiate}\) function of \(\mathrm{DRBG}_{1}\) is replaced by a request for the generation of random bits:

• \((\mathit{status}, \mathit{seed\_material}) = \mathbf{RBG3\_Generate\_request}(\mathit{DRBG}_{R}\mathit{\_state\_handle}, \mathit{keylen} + \mathit{output\_len}, \mathit{additional\_input})\).

• If (\(\mathit{status} \ne \mathrm{SUCCESS}\)), then return (\(\mathit{status}, \mathit{Invalid\_state\_handle}\)).

\(\mathbf{RBG3\_Generate\_request}\) is intended to result in the execution of the \(\mathbf{DRBG\_Generate}\) function in \(\mathrm{DRBG}_{\mathrm{R}}\) (see Sec. 2.8.3.1).¹⁸

2. When an RBG1 construction is instantiating any other DRBG (including a \(\mathrm{CTR\_DRBG}\) with a derivation function¹⁹), \(3s/2\) bits shall be obtained from a randomness source that provides a security strength of at least \(s\) bits.

a. If the randomness source is an RBG2(P) or root RBGC construction (see Fig. 16 and Fig. 18, respectively), the \(\mathbf{Get\_randomness\_source\_input}\) call in \(\mathrm{DRBG}_{1}\) is replaced by a request to reseed \(\mathrm{DRBG}_{\mathrm{R}}\), followed by a request to generate bits:

• \(\mathit{status} = \mathbf{DRBG\_Reseed\_request}(\mathit{DRBG}_{R}\mathit{\_state\_handle}, \mathit{additional\_input})\).

• If (\(\mathit{status} \ne \mathrm{SUCCESS}\)), then return (\(\mathit{status}, \mathit{Invalid\_state\_handle}\)).

• \((\mathit{status}, \mathit{seed\_material}) = \mathbf{DRBG\_Generate\_request}(\mathit{DRBG}_{R}\mathit{\_state\_handle},\)

\(3s/2, s, \mathit{additional\_input})\).

• If (\(\mathit{status} \ne \mathrm{SUCCESS}\)), then return (\(\mathit{status}, \mathit{Invalid\_state\_handle}\)).

\(\mathbf{DRBG\_Reseed\_request}\) and \(\mathbf{DRBG\_Generate\_request}\) are used here to indicate requests for the DRBG within the randomness source (\(\mathrm{DRBG}_{\mathrm{R}}\)) to execute the \(\mathbf{DRBG\_Reseed}\) function and \(\mathbf{DRBG\_Generate}\) function within \(\mathrm{DRBG}_{\mathrm{R}}\) (see Sec. 2.8.1.3 and 2.8.1.2, respectively).²⁰

b. If the randomness source is an RBG3(XOR) or RBG3(RS) construction (see Fig. 17), the \(\mathbf{Get\_randomness\_source\_input}\) call in \(\mathrm{DRBG}_{1}\) is replaced by a request for the generation of random bits:

• \((\mathit{status}, \mathit{seed\_material}) = \mathbf{RBG3\_DRBG\_Generate\_request}(\mathit{DRBG}_{R}\mathit{\_state\_handle}, 3s/2, \mathit{additional\_input})\).

• If (\(\mathit{status} \ne \mathrm{SUCCESS}\)), then return (\(\mathit{status}, \mathit{Invalid\_state\_handle}\)).

\(\mathbf{RBG3\_DRBG\_Generate\_request}\) is intended to result in the execution of the \(\mathbf{DRBG\_Generate\ function}\) in \(\mathrm{DRBG}_{\mathrm{R}}\) (see Sec. 2.8.3.1).²¹

The \(\mathbf{DRBG\_Generate\_request}\) results in the execution of the \(\mathbf{DRBG\_Generate}\) function within \(\mathrm{DRBG}_{1}\):

The \(\mathit{status}\) returned by the \(\mathbf{DRBG\_Generate}\) function shall be returned to the requesting application. If the \(\mathit{status}\) indicates a successful process, the \(\mathit{returned\_bits}\) shall also be provided to the application in response to the request.

Let \(\mathrm{DRBG}_1\) be the DRBG used by the RBG1 construction itself, with \(\mathit{RBG1\_DRBG1\_state\_handle}\) used as the state handle for the internal state of \(\mathrm{DRBG}_1\). Let \(\mathit{sub\text{-}DRBGx\_state\_handle}\) be the state handle for the internal state of \(\mathrm{sub\text{-}DRBG}_{\mathrm{x}}\).

3. The security strength that can be provided by a sub-DRBG is no more than the security strength of \(\mathrm{DRBG}_1\) (i.e., the DRBG of the RBG1 construction that is serving as the randomness source for the sub-DRBG).

An application may request the RBG1 construction to instantiate a sub-DRBG. Let \(\mathit{RBG1\_DRBG1\_state\_handle}\) be the state handle for the DRBG used by the RBG1 construction. The following represents the form of the application’s request for sub-DRBG instantiation:

\(\mathrm{DRBG}_1\) executes an \(\mathbf{Instantiate\_sub\text{-}DRBG}\) function. The \(\mathit{status}\) of the process is returned to the application with a state handle if the \(\mathit{status}\) indicates success.

The value of \(\mathit{max\_personalization\_string\_length}\) is specified in [SP_800-90A] for the DRBG type.

\(\mathbf{Instantiate\_sub\text{-}DRBG}\):

1. \(s\): The requested security strength for the sub-DRBG.

2. (Optional) \(\mathit{personalization\_string}\): An input that provides personalization information.

1. \(\mathit{status}\): The status returned from the \(\mathbf{Instantiate\_sub\text{-}DRBG}\) function (see steps 2, 3, 6, and 10). If any status other than SUCCESS is returned, an \(\mathit{invalid\ \_state}\) handle shall be returned.

2. \(\mathit{sub\text{-}DRBGx\_state\_handle}\): Used to identify the internal state for this sub-DRBG instantiation in subsequent calls to the generate function (see Sec. 4.3.2).

The internal states for \(\mathrm{DRBG}_1\) and the sub-DRBG instantiation.

1. Obtain the current internal state of \(\mathrm{DRBG}_1\) to get its instantiated security strength (shown as \(\mathit{RBG1\_DRBG1\_security\_strength}\) in step 2).

2. If \((s > \mathit{RBG1\_DRBG1\_security\_strength})\), then return \((\mathrm{ERROR\_FLAG}, \mathit{Invalid\_state\_handle})\).

3. If the length of the \(\mathit{personalization\_string} > \mathit{max\_personalization\_string\_length}\), return \((\mathrm{ERROR\_FLAG}, \mathit{Invalid\_state\_handle})\).

4. If \((s > 192)\), then \(s = 256\)

Else, if \((s \le 128)\), then \(s = 128\).

Else, \(s = 192\).

Comment: See the instructions below for the value of \(\mathit{number\_of\_bits\_to\_generate}\).

5. \((\mathit{status}, \mathit{seed\_material}) = \mathbf{DRBG\_Generate}(\mathit{RBG1\_DRBG1\_state\_handle}, \mathit{number\_of\_bits\_to\_generate}, s)\).

6. If \((\mathit{status} \ne \mathrm{SUCCESS})\), return \((\mathit{status}, \mathit{Invalid\_state\_handle})\).

7. \(\mathit{working\_state\_values} = \mathbf{Instantiate\_algorithm}(\mathit{seed\_material}, \mathit{personalization\_string})\).

8. Get the \(\mathit{sub\text{-}DRBGx\_state\_handle}\) for a currently empty internal state. If an empty internal state cannot be found, return \((\mathrm{ERROR\_FLAG}, \mathit{Invalid\_state\_handle})\).

9. Set the internal state for the new instantiation (e.g., as indicated by \(\mathit{sub\text{-}DRBGx\_state\_handle}\)):

9.1 Record the \(\mathit{working\_state\_values}\) returned from step 7.

9.2 Record any administrative information (e.g., the value of \(s\)).

10. Return \((\mathrm{SUCCESS}, \mathit{sub\text{-}DRBGX\_state\_handle})\).

Step 1 obtains \(\mathrm{DRBG}_1\)’s security strength. A description of the internal state for each DRBG type is provided in [SP_800-90A].

Steps 2 and 3 check the validity of the requested security strength \(s\) and the length of any personalization string provided for the instantiation request. An \(\mathrm{ERROR\_FLAG}\) and an invalid state handle are returned to the requesting application if either is unacceptable.

Step 4 sets the security strength to be established for the sub-DRBG instantiation based on the requested security strength \(s\).

Step 5 requests the generation of \(\mathit{seed\_material}\) at a security strength of \(s\) bits using \(\mathrm{DRBG}_1\). The \(\mathit{number\_of\_bits\_to\_generate}\) depends on \(\mathrm{DRBG}_1\)’s type:

• When \(\mathrm{CTR\_DRBG}\) without a derivation function is implemented for \(\mathrm{DRBG}_1\), \(\mathit{number\_of\_bits\_to\_generate} = \mathit{keylen} + \mathit{output\_len}\).

• Otherwise, \(\mathit{number\_of\_bits\_to\_generate} = 3s/2\).

Step 6 checks the \(\mathit{status}\) returned from step 5. If a \(\mathit{status}\) of \(\mathrm{SUCCESS}\) is not returned, the \(\mathit{status}\) and an invalid state handle are returned to the requesting application.

Step 7 invokes the appropriate instantiate algorithm in [SP_800-90A] for \(\mathrm{DRBG}_1\)’s design. Values for the working state portion of the sub-DRBG’s internal state are returned by the instantiate algorithm.

Step 8 assigns a state handle for an available internal state. If no internal state is currently available, an \(\mathrm{ERROR\_FLAG}\) and invalid state handle are returned to the requesting application.

Step 9 enters the required values into the assigned internal state for the sub-DRBG. \(\mathit{Working\_state\_values}\) will need to be parsed into the appropriate values used for the DRBG algorithm in SP 800-90A.

Step 10 returns a \(\mathit{status}\) of \(\mathrm{SUCCESS}\) and the assigned state handle to the requesting application.

The generate request received by the sub-DRBG shall result in the execution of the \(\mathbf{DRBG\_Generate}\) function:

The \(\mathit{status}\) returned by the \(\mathbf{DRBG\_Generate}\) function shall be returned to the application in response to the request. If the process is successful, the newly generated bits (\(\mathit{returned\_bits}\)) shall also be provided to the application in response to the \(\mathbf{DRBG\_Generate\_request}\).

7. For \(\mathrm{CTR\_DRBG}\) with a derivation function, \(\mathrm{Hash\_DRBG}\), or \(\mathrm{HMAC\_DRBG}\), \(3s/2\) bits shall be obtained from a randomness source, where \(s\) is the targeted security strength for the DRBG used in the RBG1 construction (\(\mathrm{DRBG}_1\)).

8. For \(\mathrm{CTR\_DRBG}\) without a derivation function in the RBG1 construction, \(\mathit{keylen} + \mathit{output\_len}\) bits shall be obtained from the randomness source, where \(\mathit{keylen}\) is the length of the key used by the block cipher used in the RBG1 construction (\(\mathrm{DRBG}_1\)).

13. If the seedlife of the DRBG within the RBG1 construction (\(\mathrm{DRBG}_1\)) is ever exceeded or a health test of the DRBG fails, the use of the RBG1 construction shall be terminated.

14. The randomness source for the DRBG within an RBG1 construction (\(\mathrm{DRBG}_1\)) must be either 1) a validated RBG2(P) construction with support for reseeding requests, 2) a validated RBG3 construction, or 3) a root RBGC construction that has support for reseed requests using either an RBG3 construction or a physical full-entropy source as its initial randomness source.

15. The randomness source must provide the requested number of bits at a security strength of \(s\) bits or higher, where \(s\) is the targeted security strength for the DRBG within the RBG1 construction (\(\mathrm{DRBG}_1\)).

19. A physically secure channel must be used to insert the seed material from the randomness source into the DRBG of the RBG1 construction (\(\mathrm{DRBG}_1\)).

8. For CTR_DRBG with a derivation function, Hash_DRBG, or HMAC_DRBG, \(3s/2\) bits shall be obtained from the RBG1 construction for instantiation of the sub-DRBG, where \(s\) is the requested security strength for the target sub-DRBG.

9. For CTR_DRBG without a derivation function used by the sub-DRBG, \(\mathit{keylen} + \mathit{output\_len}\) bits shall be obtained from the RBG1 construction for instantiation, where \(\mathit{keylen}\) is the length of the key to be used by the block cipher in the target sub-DRBG.

These variants may affect the implementation of a \(\mathbf{Get\_entropy\_bitstring}\) process (represented as a \(\mathbf{Get\_entropy\_bitstring}\) procedure; see Sec. 2.8.2 and 3.1) by accessing the entropy sources directly or via the \(\mathbf{Get\_conditioned\_input}\) or \(\mathbf{Get\_conditioned\_full\_entropy\_input}\) procedures specified in Sec. 3.2.2 during instantiation and reseeding (see Sec. 5.2.1 and 5.2.3). That is, when seeding and reseeding an RBG2(P) construction (including a DRBG within an RBG3 construction, as discussed in Sec. 6), Method 1 in Sec. 2.3 is used to combine the entropy from the entropy sources, and Method 2 is used when instantiating and reseeding an RBG2(NP) construction.

The request results in the execution of the \(\mathbf{DRBG\_Instantiate}\) function within the DRBG:

The \(\mathbf{DRBG\_Instantiate}\) function returns the \(\mathit{status}\) of the process, which is then provided to the application in response to the request. If the process is successful, a state handle for the instantiation (e.g., \(\mathit{RBG2\_DRBG\_state\_handle}\)) is also returned from the \(\mathbf{DRBG\_Instantiate}\) function and may be forwarded to the application.²⁴

[SP_800-90A] uses a \(\mathbf{Get\_randomness\_source\_input}\) call in the \(\mathbf{DRBG\_Instantiate}\) function to obtain the entropy needed for instantiation. Let \(\mathit{counting\_method}\) indicate the method for counting entropy from the entropy sources (i.e., Method 1 only counts entropy provided by physical entropy sources, and Method 2 counts entropy from both non-physical and physical entropy sources; see Sec. 2.3). Let \(\mathit{keylen}\) be the length of the key to be used by the cryptographic primitive, and let \(\mathit{output\_len}\) be the length of its output block.

a. If all entropy sources provide full-entropy output or meet the requirements in [SP_800-90A], the \(\mathbf{Get\_randomness\_source\_input}\) call is replaced by:

• \((\mathit{status}, \mathit{seed\_material}) = \mathbf{Get\_entropy\_bitstring}(\mathit{keylen} + \mathit{output\_len}, \mathit{counting\_method})\).

• If (\(\mathit{status} \ne \mathrm{SUCCESS}\)), then return (\(\mathit{status}, \mathit{Invalid\_state\_handle}\)).

The output of the entropy source(s) shall be concatenated to obtain the \(\mathit{keylen} + \mathit{output\_len}\) full-entropy bits to be returned as \(\mathit{seed\_material}\).

b. If one or more entropy sources do not provide full-entropy output, the \(\mathbf{Get\_randomness\_source\_input}\) call is replaced by: ²⁵

• \((\mathit{status}, \mathit{seed\_material}) = \mathbf{Get\_conditioned\_full\_entropy\_input}(\mathit{keylen} + \mathit{output\_len}, \mathit{counting\_method})\).

²⁵ See Sec. 3.2.2.2 for a specification of the \(\mathbf{Get\_conditioned\_full\_entropy\_input}\) function.

• If (\(\mathit{status} \ne \mathrm{SUCCESS}\)), then return (\(\mathit{status}, \mathit{Invalid\_state\_handle}\)).

3. For CTR_DRBG with a derivation function, Hash_DRBG, or HMAC_DRBG used as the DRBG, the entropy sources shall provide \(3s/2\) bits of entropy to establish the security strength.

a. If the implementer wants full entropy in the bitstring to be provided to the DRBG, the \(\mathbf{Get\_randomness\_source\_input}\) call is replaced by:

• \((\mathit{status}, \mathit{seed\_material}) = \mathbf{Get\_conditioned\_full\_entropy\_input}(3s/2, \mathit{counting\_method})\).

• If (\(\mathit{status} \ne \mathrm{SUCCESS}\)), then return (\(\mathit{status}, \mathit{Invalid\_state\_handle}\)).

b. Otherwise, the \(\mathbf{Get\_randomness\_source\_input}\) call is replaced by:

• \((\mathit{status}, \mathit{seed\ material}) = \mathbf{Get\_entropy\_bitstring}(3s/2, \mathit{counting\_method})\)

• If \((\mathit{status} \ne \mathrm{SUCCESS})\), then return \((\mathit{status}, \mathit{Invalid\_state\_handle})\).

If a reseed of the RBG was not requested by the application prior to requesting the generation of pseudorandom bits, or a \(\mathit{status}\) of SUCCESS was returned by the \(\mathbf{DRBG\_Reseed}\) function in response to a reseed request, pseudorandom bits are requested as follows (see Sec. 2.8.1.2):

The request shall result in the execution of a \(\mathbf{DRBG\_Generate}\) function by the DRBG (see Sec. 2.8.1.2) and checking the \(\mathit{status}\) returned by the \(\mathbf{DRBG\_Generate}\) function:

• \((\mathit{status}, \mathit{returned\_bits}) = \mathbf{DRBG\_Generate}(\mathit{RBG2\_DRBG\_state\_handle}, \mathit{requested\_number\_of\_bits}, \mathit{requested\_security\_strength}, \mathit{additional\_input})\).

• If \((\mathit{status} \ne \mathrm{SUCCESS})\), then return \((\mathit{status}, \mathit{Null})\).

The \(\mathbf{DRBG\_Generate}\) function returns the \(\mathit{status}\) of the process, which shall also be returned to the application in response to the \(\mathbf{DRBG\_Generate\_request}\). If the \(\mathit{status}\) indicates that the generation was successful, the requested random bits \((\mathit{returned\_bits})\) are also provided by the \(\mathbf{DRBG\_Generate}\) function and forwarded to the application.

However, the DRBG shall either be reseeded or re-instantiated before executing the \(\mathbf{DRBG\_Generate}\) function if it has output \(2^{17}\) or more bits since instantiation or the last reseed process. A request does not need to be interrupted if that output threshold is exceeded while completing a \(\mathbf{DRBG\_Generate\_request}\). For example, if \(2^{17}-1\) bits have already been output from the DRBG when a \(\mathbf{DRBG\_Generate\_request}\) is received for any amount up to the maximum number of bits that may be requested in a single invocation (see SP 800-90A), the generate process may be fulfilled without interruption. The DRBG shall then be reseeded or re-instantiated before the next execution of a \(\mathbf{DRBG\_Generate}\) function.

If the DRBG receives a \(\mathbf{DRBG\_Reseed\_request}\) or if the DRBG is scheduled for a reseed based on implementation-selected criteria, the \(\mathbf{DRBG\_Reseed}\) function shall be executed (see Sec. 2.8.1.3):

The \(\mathbf{DRBG\_Reseed}\) function returns the \(\mathit{status}\) of the reseed process, which shall be returned to the application if requested using a \(\mathbf{DRBG\_Reseed\_request}\).

The \(\mathbf{DRBG\_Reseed}\) function uses a \(\mathbf{Get\_randomness\_source\_input}\) call to obtain the entropy needed for reseeding the DRBG (see Sec. 2.8.1.3 and [SP_800-90A]). The DRBG is reseeded at the instantiated security strength recorded in the DRBG’s internal state. The \(\mathbf{Get\_randomness\_source\_input}\) call in SP 800-90A shall be replaced with the following:

2. For CTR_DRBG with a derivation function, Hash_DRBG, or HMAC_DRBG, replace the \(\mathbf{Get\_randomness\_source\_input}\) call in the \(\mathbf{DRBG\_Reseed}\) function with the following:²⁷

a. If the implementer wants full entropy in the returned bitstring, the \(\mathbf{Get\_randomness\_source\_input}\) call is replaced by:

b. Otherwise, the \(\mathbf{Get\_randomness\_source\_input}\) call is replaced by:

or

6. The DRBG shall be reseeded before generating output if the DRBG has produced \(2^{17}\) or more bits of output since instantiation or the last reseeding process.

7. When instantiating and reseeding CTR_DRBG without a derivation function, \(\mathit{keylen} + \mathit{output\_len}\) bits with full entropy (where \(\mathit{keylen}\) is the length of the key to be used by the cryptographic primitive and \(\mathit{output\_len}\) is the length of its output block) or as otherwise specified in [SP_800-90A] shall be obtained either directly from the entropy sources or

²⁷ See Sec. 2.8.2 and 3.1 for discussions of the \(\mathbf{Get\_entropy\_bitstring}\) function.

8. For CTR_DRBG with a derivation function, Hash_DRBG, or HMAC_DRBG, a bitstring with at least \(3s/2\) bits of entropy shall be obtained from the entropy sources to instantiate the DRBG at a security strength of \(s\) bits. When reseeding is performed, a bitstring with at least \(s\) bits of entropy shall be obtained from the entropy source(s). The entropy may be obtained directly from the entropy source(s) or via an external vetted conditioning function (see Sec. 3.2.2).

5. When instantiating and reseeding \(\mathrm{CTR\_DRBG}\) without a derivation function, \(\mathit{keylen} + \mathit{output\_len}\) bits with full entropy or as otherwise specified in SP 800-90A shall be obtained either directly from the entropy source(s) or via an external vetted conditioning function that provides full-entropy output (see Sec. 3.2.2.2).

6. For \(\mathrm{CTR\_DRBG}\) with a derivation function, \(\mathrm{Hash\_DRBG}\), or \(\mathrm{HMAC\_DRBG}\), a bitstring with at least \(3s/2\) bits of entropy²⁹ shall be obtained from the entropy sources to instantiate the DRBG at a security strength of \(s\) bits. When reseeding is performed, a bitstring with at least \(s\) bits of entropy shall be obtained from the entropy source(s). The entropy may be obtained directly from the entropy source(s) or via an external vetted conditioning function (see Sec. 3.2.2).

When \(n\) bits of output are requested from an RBG3(XOR) construction, \(n\) bits of output from the DRBG are XORed with \(n\) full-entropy bits that are obtained directly from the entropy source(s) or from a combination of validated entropy source(s) and an external vetted conditioning function that provides full-entropy output (see Sec. 3.2.2.2). When the entropy sources are working properly,³⁰ an \(n\)-bit output from the RBG3(XOR) construction is said to provide \(n\) bits of entropy or to support a security strength of \(n\) bits. Appendix B.5 provides an example of an RBG3(XOR) design.

where \(\mathit{requested\_security\_strength}\) and \(\mathit{personalization\_string}\) are optional. If the \(\mathit{requested\_security\_strength}\) parameter is provided and exceeds the highest security strength that can be supported by the DRBG, an error indication shall be returned with an invalid \(\mathit{state\_handle}\) (see Sec. 2.8.3.1).

If the \(\mathit{requested\_security\_strength}\) is provided and acceptable (i.e., \(\mathit{requested\_security\_strength}\) does not exceed the highest security strength that can be supported by the DRBG; see Sec. 2.8.3.1) or if the \(\mathit{requested\_security\_strength}\) parameter is not provided, the \(\mathbf{Instantiate\_RBG3\_DRBG\_request}\) received by the RBG3(XOR) construction shall result in the execution of the \(\mathbf{RBG3(XOR)\_Instantiate}\) function below. The \(\mathit{status}\) returned by the \(\mathbf{RBG3(XOR)\_Instantiate}\) function shall be returned to the application in response to the \(\mathbf{Instantiate\_RBG3\_DRBG\_request}\). The return of the \(\mathit{state\_handle}\) is optional if only a single instantiation is allowed by an implementation.

Let \(s\) be the highest security strength that can be supported by the DRBG. The DRBG in the RBG3(XOR) construction is instantiated as follows:

\(\mathbf{RBG3(XOR)\_Instantiate}\):

1. \(\mathit{personalization\_string}\): An optional (but recommended) personalization string.

1. \(\mathit{status}\): The status returned by the \(\mathbf{RBG3(XOR)\_Instantiate}\) function.

2. \(\mathit{RBG3\_DRBG\_state\_handle}\): The returned state handle for the internal state of the DRBG or an invalid state handle.

1. \((\mathit{status}, \mathit{RBG3\_DRBG\_state\_handle}) = \mathbf{DRBG\_Instantiate}(s, \mathit{personalization\_string})\).

2. If \((\mathit{status} \ne \mathrm{SUCCESS})\), then return \((\mathit{status}, \mathit{Invalid\_state\_handle})\).

3. Return \((\mathrm{SUCCESS}, \mathit{RBG3\_DRBG\_state\_handle})\).

In step 1, the DRBG is instantiated at a security strength of \(s\) bits. \(\mathit{RBG3\_DRBG\_state\_handle}\) (if returned) is the state handle for the internal state of the DRBG used within the RBG3(XOR) construction.

In step 2, if the \(\mathit{status}\) returned from step 1 does not indicate a success, then return the \(\mathit{status}\) with an invalid state handle.

In step 3, the \(\mathit{status}\) and \(\mathit{RBG3\_DRBG\_state\_handle}\) that were obtained in step 1 are returned to the requesting application.

where \(\mathit{RBG3\_DRBG\_state\_handle}\) was provided during instantiation (see Sec. 6.4.1.1), \(n\) is the number of bits to be generated and returned to the application, and \(\mathit{additional\_input}\) is optional.

The \(\mathbf{RBG3\_DRBG\_Generate\_request}\) received by the RBG3(XOR) construction shall result in the execution of the \(\mathbf{RBG3(XOR)\_Generate}\) function below. The output of that function shall be returned to the application in response to the \(\mathbf{RBG3\_DRBG\_Generate\_request}\).

Let \(s\) be the security strength instantiated for the DRBG (i.e., the highest security strength that can be supported by the DRBG; see Sec. 6.4.1.1), and let the \(\mathit{RBG3\_DRBG\_state\_handle}\) be the value returned by the instantiation function for RBG3(XOR)’s DRBG instantiation. Random bits with full entropy shall be generated by the RBG3(XOR) construction using the following generate function with the values of \(n\) and \(\mathit{additional\_input}\) provided in the \(\mathbf{DRBG\_Generate\_request}\) as input:

\(\mathbf{RBG3(XOR)\_Generate}\):

1. \(\mathit{RBG3\_DRBG\_state\_handle}\): The state handle of the DRBG used by the RBG3 construction.

2. \(n\): The number of bits to be generated.

3. \(\mathit{additional\_input}\): Optional additional input.

1. \(\mathit{status}\): The status returned by the \(\mathbf{RBG3(XOR)\_Generate}\) function.

2. \(\mathit{returned\_bits}\): The \(n\) bits generated by the RBG3(XOR) construction or a \(\mathit{Null}\) string.

1. \((\mathit{status}, \mathit{ES\_bits}) = \mathbf{Request\_entropy}(n)\). (See the notes below for customizing this step.)

2. If \((\mathit{status} \ne \mathrm{SUCCESS})\), then return \((\mathit{status}, \mathit{Null})\).

3. \((\mathit{status}, \mathit{DRBG\_bits}) = \mathbf{DRBG\_Generate}(\mathit{RBG3\_DRBG\_state\_handle}, n, s, \mathit{additional\_input})\).

4. If \((\mathit{status} \ne \mathrm{SUCCESS})\), then return \((\mathit{status}, \mathit{Null})\).

5. \(\mathit{returned\_bits} = \mathit{ES\_bits} \oplus \mathit{DRBG\_bits}\).

6. Return \((\mathrm{SUCCESS}, \mathit{returned\_bits})\).

Step 1 requests that the entropy source(s) generate \(n\) bits. Since full-entropy bits are required, the (placeholder) \(\mathbf{Request\_entropy}\) call shall be replaced by one of the following:

The \(\mathbf{Get\_entropy\_bitstring}\) function³¹ shall use Method 1³² to obtain the \(n\) full-entropy bits that were requested to produce \(\mathit{ES\text{-}bits}\).