Take Their Advice: Disregard Their Earlier Advice!

The field of cybersecurity is filled with frequent dire warnings. Software vulnerabilities are discovered, accidents in design and implementation. Attack trends are detected, from criminals, foreign militaries, and pranksters. But a recent pair of announcements took an unusual new form. One of the most respected commercial names in cybersecurity warned its customers to stop using two of its products, while a U.S. government agency has announced that one of its official decisions may have been quite wrong.

As I have written here and here, information security requires a good source of randomness for tasks like cryptographic key generation.

Practical cryptography also needs good pseudorandom functions, algorithms that are deterministic (they generate the same output each time they are are started with the same key) but with output statistically indistinguishable from truly random data.

NIST, the National Institute of Standards and Technology, published SP 800-90A, Recommendation for Random Number Generation Using Deterministic Random Bit Generators, in 2007, with parts of it later being included in ISO 18031. It defines four pseudorandom number generators purported to be cryptographically secure: Hash_DRBG and HMAC_DRBG using hash functions and hashed-based message authentication codes, respectively; CTR_DRBG using block ciphers; and Dual_EC_DRBG, using elliptic curve cryptography. The last of these is the new focus of attention.

Bruce Schneier questioned Dual_EC_DRBG a few months later in commentary in Wired. Detailed analysis in 2006 and 2007 showed that it had some bias, meaning that its output was noticeably non-random.

Next, a presentation in the rump session of CRYPTO 2007 showed that Dual_EC_DRBG might have a back door. As its conclusion made clear, the researchers were not saying that NIST intentionally built a back door into the algorithm. They also suggested some improvements. But given the arcane nature of cryptographically secure pseudorandom bit generator algorithms, and the fact that Dual_EC_DRBG was unusually slow, three orders of magnitude slower than the other three algorithms in SP 800-90A, none of this was really household news.

Then the Snowden Revelations of this past summer suggested that this algorithm was in fact a backdoor designed into the algorithm by the NSA, compromising any cryptosystem based on it.

On September 9, 2013, NIST announced that it was basically demoting SP 800-90A and the subsequent SP 800-90B/C, and that it now “strongly recommends” against the use of Dual_EC_DRBG. The following day the director of NIST issued the statement that “NIST would not deliberately weaken a cryptographic standard.”

(With the U.S. Government’s shutdown, the NIST web sites are down. But presumably the surveillance continues unabated.)

Meanwhile the security firm RSA had been using Dual_EC_DRBG as the default and recommended random number generator in both their BSAFE toolkit and their Data Protection Manager. On September 20 RSA warned customers to change to a different algorithm, saying “RSA always acts in the best interest of its customers and under no circumstances does RSA design or enable any backdoors in our products. Decisions about the features and functionality of RSA products are our own.”

For more technical details on the Dual_EC_DRBG drawbacks, see Matthew Green’s analysis.

In Learning Tree’s Cloud Security Essentials course we try to keep up to date on the latest cybersecurity developments influencing cloud computing. OK, fine, stay away from products relying on Dual_EC_DRBG. But what will we learn next?

Bob Cromwell

Type to search blog.learningtree.com

Do you mean "" ?

Sorry, no results were found for your query.

Please check your spelling and try your search again.