Cited by 310Cryptographic Implementations and SecurityCryptography and Residue ArithmeticCryptography and Data Security

The DOI matches its Crossref record; 4 of the 4 references it cites were found in a registry or an index; none of the 6 sources its claims cite is checked for support yet.

Recommendation for Random Number Generation Using Deterministic Random Bit Generators

Open access

Abstract

AuthorityThis publication has been developed by NIST to further its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3541 et seq., Public Law (P.L.) 113-283.NIST is responsible for developing information security standards and guidelines, including minimum requirements for Federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate Federal officials exercising policy authority over such systems.This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130, Section 8b(3), Securing Agency Information Systems, as analyzed in Circular A-130, Appendix IV: Analysis of Key Sections. Supplemental information is provided in Circular A-130, Appendix III, Security of Federal Automated Information Resources.Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on Federal agencies by the Secretary of Commerce under statutory authority.Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other Federal official.This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States.Attribution would, however, be appreciated by NIST.

Overview

AI snapshot

Written from the paper’s full text.

TL;DR

NIST SP 800-90A Rev. 1 specifies approved Deterministic Random Bit Generators (DRBGs) — Hash_DRBG, HMAC_DRBG, and CTR_DRBG — along with the requirements for instantiating, reseeding, generating from, and health-testing them. It defines the security strengths, entropy requirements, and output limits under which these mechanisms are considered secure.

Key findings

  • The Recommendation supports exactly four security strengths: 112, 128, 192, or 256 bits; the security strength of output is `min(output_length, DRBG_security_strength)`, and concatenating outputs cannot exceed the instantiated strength.
  • Approved mechanisms are hash-based (Hash_DRBG, HMAC_DRBG) and block-cipher-based (CTR_DRBG using TDEA, AES-128, AES-192, or AES-256). All were judged to provide acceptable security when published, and diversity of mechanisms allows transition if attacks are found on one class.
  • Output constraints: hash-based DRBGs permit up to 2^48 generate requests of up to 2^19 bits each; AES CTR_DRBG the same; TDEA CTR_DRBG is limited to 2^32 requests of 2^13 bits. These limits exist to avoid a theoretical distinguishing attack (probability of distinguishing AES CTR_DRBG from ideal random at maximum output ≈ 2^-57; TDEA case ≈ 2^-6 in the described game).
  • All DRBG mechanisms in the Recommendation are designed to provide backtracking resistance; prediction resistance requires reseeding with fresh entropy (at least the security strength) between consecutive requests.
  • Dual_EC_DRBG was removed in Revision 1, along with the elliptic-curve appendices.

Methods

  • This is a specification/standards document, not an empirical study: it defines DRBG mechanisms via pseudocode "envelopes" (instantiate, reseed, generate, uninstantiate, health test) around underlying algorithms, plus auxiliary derivation functions (Hash_df, Block_Cipher_df) and BCC/Block_Encrypt primitives.
  • Conformance testing is to be conducted within the CMVP and CAVP frameworks; requirements are indicated by "shall," and some are out of scope for CMVP/CAVP validation.
  • Informative appendices provide conversion routines (Appendix A), worked pseudocode examples for each mechanism (Appendix B), and DRBG mechanism selection guidance with a cost/constraint summary table (Appendix C).

Limitations

  • Stated: "The precise structure, design and development of a random bit generator is outside the scope of this document"; entropy source design/validation is deferred to SP 800-90B and RBG construction to SP 800-90C.
  • Stated: Hash_DRBG has known problems when instantiated with insufficient entropy for the requested strength and later supplied enough entropy via additional input during a generate request — though these do not affect security when instantiated with the entropy specified in the Recommendation.
  • Stated: the CTR_DRBG distinguishing attack is "theoretical — it poses no practical threat to any real-world application of the DRBG"; the output limits are nonetheless required.

Model-written summary. Check it against the paper before relying on it.

Integrity signals

Registry

Crossref · 10.6028/nist.sp.800-90ar1

Cites

4 of 4 references verified0 citation errors · 0 not checkable

Statistics

Nothing to recompute.

Verification

Claims the paper makes

96 Own interpretation · 10 No basis given · 7 Own method · 6 Not checked yet

Verify all 6 references — free account
  • Probably not a substantial claim. 91
  • It may state two separate claims as one. 28
99 of 99
  • The authors state this as an assumption.

    The adversary is incapable of performing the work required to negate the claimed security strength of the DRBG.

    “This assumes that the adversary is incapable of performing the work required to negate the claimed security strength of the DRBG.”
  • The authors state this as an assumption.

    The adversary is incapable of performing work that matches the claimed security strength of the RBG.

    “incapable of performing work that matches the claimed security strength of the RBG”
  • The paper relies on this without support.

    The security of the DRBG depends on the secrecy of the entropy input.

    “The security of the DRBG depends on the secrecy of the entropy input.”
  • The authors state this as an assumption.

    An approved hash function used in the HMAC construction is a pseudorandom function family.

    “The security of HMAC_DRBG is based on the assumption that an approved hash function used in the HMAC construction is a pseudorandom function family.”
  • The authors state this as an assumption.

    The pseudorandomness of HMAC is a widely used assumption in designs.

    “Note that the pseudorandomness of HMAC is a widely used assumption in designs, and the HMAC_DRBG requires far less demanding properties of the underlying hash function than Hash_DRBG.”
5 of 5

Claims other papers make about this one

Each is checked against this paper’s own text: does it say what the citing paper says it does?

Self-check

Percentages, sums and reported differences re-computed from the paper’s own numbers.

Each contradiction between two passages listed here was confirmed by an independent check.

3 of 3

Citations

Cites

1 retracted

Show all 4 references

Cited by

Sorted by citations

See all 310

Metadata

Authors
Barker, E. B., & Kelsey, J. M.
Published
2015-06
OpenAlex
W4298403653
Cited by
304
References
4
Citations by year
2026: 49 · 2025: 53 · 2024: 27 · 2023: 31 · 2022: 22 · 2021: 18 · 2020: 19 · 2019: 26 · 2018: 13 · 2017: 16 · 2016: 8 · 2015: 4
Type
report
Language
en
Open access
Funders
National Institute of Standards and Technology
Topics
  • Physical Sciences › Computer Science › Artificial Intelligence › Cryptographic Implementations and Security
  • Physical Sciences › Computer Science › Information Systems › Cryptography and Residue Arithmetic
  • Physical Sciences › Computer Science › Computer Networks and Communications › Cryptography and Data Security
Keywords
random number generation, random bit generation, cryptographic key generation, information security standards

About these checks

Registry, retraction, Cites and statistics results are computed, not judged, with one exception: a printed reference that no index lists is read once by a model before it counts as a citation error. Claims are extracted by a model and kept only when their quote appears verbatim in the text; each cited source is then checked, with a model’s help, for whether it says what the claim relies on. Those verdicts can be wrong — read the claim’s quote and the cited source before relying on one.

A language model drew the claims from the paper on 2026-10-09, under version 3 of the claim definition (model deepseek-v4.1-flash, prompt extract-v3).

A second model labelled each claim on 2026-10-09 (model jev-1.13-20260917, definition revision gold-guideline-v0.2).

Statistics and arithmetic are recomputed, not judged.

Confidence bands are shown only for fields calibrated on our annotated test set. None is calibrated yet, so no band is shown.

What counts as a claim ›How we measure confidence ›How we check this ›

Are you an author, or do you see a problem with this page? Request a review