NIST SP 800-90 Historical Information

November 21, 2014: NIST requests comments on the latest revision of NIST SP 800-90A, Recommendation for Random Number Generation Using Deterministic Random Bit Generators, which is dated November 2014. This document specifies Deterministic Random Bit Generators based on approved hash functions (as specified in FIPS 180-4), HMAC (as specified in FIPS 198-1) and block ciphers (as specified in FIPS 197 for AES, and SP 800-67 for TDEA). This revision removes the previously approved Dual_EC_DRBG that was based on the use of elliptic curves and includes a number of other changes that are listed in the final appendix of the document. The comment period ended December 31, 2014.

Comments Received on Draft SP 800-90A (December 2014)

April 21, 2014: NIST requests comments on a revision of NIST SP 800-90A, Recommendation for Random Number Generation Using Deterministic Random Bit Generators. This revision removes the Dual_EC_DRBG from the document. The comment period ended May 23, 2014.

Comments Received for Draft SP 800-90A Rev. 1 (2nd draft)

September 10, 2013: In light of recent reports, NIST is reopening the public comment period for Special Publication 800-90A and draft Special Publications 800-90B and 800-90C.  In addition, the Computer Security Division has released a supplemental ITL Security Bulletin titled "NIST Opens Draft Special Publication 800-90A, Recommendation for Random Number Generation Using Deterministic Random Bit Generators, For Review and Comment (Supplemental ITL Bulletin for September 2013)" to support the draft revision effort.

Comments Received Draft SP 800-90 A Rev. 1, B and C (469 KB)

Comments Received on Draft SP 800-90A (2011)

Comments received in 2006 in response to the original request for comments on SP 800-90.

Background: Public concern has been expressed that one of the random bit generators in SP 800-90A, the Dual_EC_DRBG, could contain a backdoor when used with the parameters specified in the publication. This could allow attackers to successfully predict the secret cryptographic keys that form the foundation for the assurances provided by security products. Cryptographers identified this potential weakness during the development of this guideline, and the issue was initially mitigated by providing mechanisms to generate alternative parameters that would not be susceptible to this weakness. However, news reports on leaked classified information have heightened concern over the possibility of a backdoor in this algorithm.

In response, NIST issued an ITL Bulletin in September 2013 that provided a high-level discussion of the issues, announced that the SP 800-90 series of publications were being reopened for a 60-day public comment period, and recommended that the Dual_EC_DRBG no longer be used, pending the resolution of the security concerns. The comments subsequently received during the public-comment period included several requests for the removal of the Dual_EC_DRBG from SP 800-90A.

The comment period for the SP 800-90 publications closed on November 6, 2013. It is clear from the received comments and conversations with representatives from industry and academia that the public does not have confidence in the security provided by the Dual_EC_DRBG. Although it is possible that the concern could be addressed by generating new parameters using the method in SP 800-90A, after reviewing these comments and conducting its own review of the algorithm, NIST has decided to remove the DRBG from the document.

Next Steps: Pending review of public comments on this revised draft, NIST intends to publish a final version of SP800-90A that formally withdraws the Dual_EC_DRBG as an approved DRBG. NIST does not intend to provide a transition period allowing continued use of Dual_EC_DRBG by vendors or users after its removal from SP 800-90A. Users and implementers would be instructed to transition to one of the three other approved DRBGs specified in SP 800-90A as soon as possible. As part of the transition plan, NIST’s Cryptographic Algorithm Validation Program (CAVP) would update the validation list for these implementations to reflect the decision that this algorithm would no longer be approved. The Cryptographic Module Validation Program (CMVP) would ensure that modules that depend on an approved DRBG have an alternative DRBG available for use.