NIST's cryptographic standards have been drawing objections from the cryptographic community for decades. In 2013, NIST finally understood that one of its standards had been deliberately sabotaged, and initiated a "review of its cryptographic standards development process".
In February 2014, NIST released a draft report entitled "NIST cryptographic standards and guidelines development process". NIST requested comments by 18 April 2014, a week from now, by email to crypto-review@nist.gov. Today I sent NIST the comments shown below (starting "Dear Sirs").
Disclosure: I've received three grants from NIST, most recently a "Cryptographic competitions" grant. I don't think this is biasing my comments in favor of NIST, but you can decide for yourself.
[2022.01.09 update: Updated links above.]
Dear Sirs:
Two independent public studies in early 2006, one by Gjøsteen and one by Schoenmakers and Sidorenko, showed clearly and indisputably that NIST's proposed Dual EC PRNG flunked the well-established definition of PRNG security. (I'm writing "NIST's" because, at the time, NIST was failing to properly attribute Dual EC to NSA.)
Did NIST drop this cryptographically unsound PRNG? No. NIST went ahead and standardized it.
Shumow and Ferguson in 2007 demonstrated that whoever had generated the Dual EC constants could easily have put a back door into Dual EC. Schneier wrote an essay saying that "both NIST and the NSA have some explaining to do" and recommending "not to use Dual_EC_DRBG under any circumstances." The consensus of the public cryptographic community was the Dual EC was dead and buried, never to be seen again.
Did NIST withdraw the standard? No. NIST continued to maintain and promote the standard. NIST issued 73 validation certificates for Dual EC implementations between July 2008 and March 2014.
News reports in September 2013 indicated that Dual EC did in fact contain a back door generated by NSA. Presumably this back door, a 78-digit secret number, is also known to many other organizations that have penetrated NSA's internal security. AP reported in June 2013 that half a million contractors have Top Secret clearance; other reports show that NSA makes heavy use of off-the-shelf hardware and software; I could keep listing reasons to question how well NSA keeps secrets, but I don't think that this is a matter of dispute.
Finally NIST took steps to withdraw the standard. NIST's "Cryptographic Standards and Guidelines Development Process" draft now acknowledges "security concerns" in the standard. But the big problem here is not the lack of security in this particular standard; the big problem here is the lack of attention to security in NIST's standardization process.
Does the draft acknowledge that NIST's standardization process is vulnerable to sabotage? Does the draft propose mechanisms that would protect the process against sabotage? No, and no. Instead the draft tries to convince the reader that NIST develops "the most secure and trusted cryptographic standards" and that these standards provide "high-quality, cost-effective security mechanisms."
Dual EC is not the only troublesome example of a NIST cryptographic standard. The DES key size was widely criticized from the outset, for example, but NIST continued to promote DES for two decades, making the inevitable upgrade vastly more expensive than it should have been. As another example, DSA was widely criticized for many more reasons, is still promoted by NIST, and is responsible for a seemingly neverending series of security problems in deployed systems. The complete failure of ECDSA signature security in the PlayStation 3 was caused by exactly the DSA/ECDSA misfeature that two decades earlier Rivest had objected to as giving the "poor user ... enough rope with which to hang himself—something a standard should not do."
Does the draft acknowledge that for many years NIST was ignoring security feedback from the cryptographic community? Does the draft propose mechanisms to prevent NIST from promoting insecure cryptographic standards? No, and again no.
Even worse, in the past decade NIST has been rushing so many cryptographic standards out the door that the quality of review has obviously been compromised. Putting together one good standard, SHA-3, involved 200 cryptographers around the world and took years of sustained public effort, but during the same period NIST also published FIPS 186-3 (signatures), FIPS 198-1 (message authentication), SP 800-38E (disk encryption), SP 800-38F (key wrapping), SP 800-56C (key derivation), SP 800-57 (key management), SP 800-67 (block encryption), SP 800-108 (key derivation), SP 800-131A (key lengths), SP 800-133 (key generation), and SP 800-152 (key management), not to mention related protocol documents such as SP 800-81r1. Why should these NIST publications be trusted? Who has actually reviewed the security of these cryptographic mechanisms, and how comprehensive was the review?
I don't mean to suggest that public review during this period was focused entirely on SHA-3. For example, the cryptographic community caught a severe security flaw in EAX Prime, and a less severe but still troublesome flaw in the security "proofs" for GCM. One can view EAX Prime as a success story, where the flaw was caught early enough to stop NIST's standardization process. However, GCM is a failure story, where NIST standardization came years before the flaw was discovered. Is this because the discovery of the GCM flaw had been waiting for some critical scientific advance? No. It is because NIST keeps biting off more than it can chew, churning out so many proposed cryptographic standards that the time required for proper security review simply does not exist.
Let me now comment on some of the things that the draft does say.
The draft claims that, to be "widely adopted," standards must "be robust and have the confidence of the cryptographic community." The unfortunate reality is that NIST standardization has, time and time again, prompted wide adoption of algorithms that were not actually robust and that had received serious objections from the cryptographic community, such as DES and DSA. NIST standardization misled the implementors and users into thinking that these algorithms were particularly safe. The cryptographic community does have confidence in AES and SHA-3, thanks to the focused competitions that produced those standards, but very few of NIST's standards are produced by such competitions.
The draft lists "Transparency" as the first principle guiding NIST's standardization processes, but later states that NIST is "statutorily required to consult with the NSA on standards." Is there any statutory requirement for NIST to take secret input from NSA? NIST might be able to regain some public trust by adopting a policy of recording and immediately publishing all communication between NIST and NSA. This would not stop NSA from paying third parties to pass messages to NIST, but NIST could issue regulations requiring financial disclosures, and in any case the basic policy would be a useful first step towards true transparency.
The draft also states "Continuous improvement" as a guiding principle, claiming that "the cryptographic community is encouraged to identify weaknesses, vulnerabilities, or other deficiencies in cryptographic functions specified in NIST publications." But actions speak louder than words. After NIST ignored serious objections to DES, ignored serious objections to DSA, and ignored serious objections to Dual EC, why should cryptographers believe that NIST is actually interested in feedback? If NIST's procedures have changed recently, why doesn't the draft say so?
I'm also troubled by security feedback being labeled as a reason for "improvement." Given the reckless pace at which NIST has been publishing cryptographic standards, it's hardly a surprise that those standards have "weaknesses" and need "improvement." How can NIST believe that this innocent-until-proven-guilty approach to cryptographic standardization is producing "the most secure and trusted cryptographic standards"? NIST should delay standardization to wait for clear evidence of adequate public review, and should abort standardization if the public review does not produce a solid consensus on security.
When I heard about this draft I assumed that NIST had engaged in (1) an honest retrospective review of known security flaws in NIST standards and (2) an honest analysis of ways in which those flaws could have been avoided by modifications in NIST's standardization process. The current draft is, unfortunately, very far from this, and as a result is very difficult to take seriously.