On 09/07/2013 11:32 AM, Gary wrote: > ... > > Here's a list of highlights from Bruce's article back > then[3]:... > > "... > My recommendation, if you're in need of a random-number generator, is > not to use Dual_EC_DRBG under any circumstances. If you have to use > something in SP 800-90, use CTR_DRBG or Hash_DRBG." > > ... I count about 65 hits on Dual_EC_DRBG -- including the OpenSSL > FIPS module. ... > But I am surprised to find just how many have implemented Dual_EC_DRBG > despite all the warnings against it in light of how crucial random > number generation is to the integrity of PKI.
I can shed some light, at least regarding the implementation of the OpenSSL FIPS Object Module. The Dual EC DRBG was implemented at the request of a paying customer[*]. We were well aware at the time of the dubious reputation of that algorithm, but it is a formal published standard. There is no disgrace in *implementing* weak cryptography; OpenSSL already contains some implementations of known weak crypto. The sin is in *using* weak cryptography when not forced to by compelling circumstances. And that's the rub. Cryptography in the U.S. Federal government is heavily constrained by policy. FIPS 140-2 for instance, which the OpenSSL FIPS module was specifically created to satisfy. I've long been on the record as saying, loud and clear, that you shouldn't use FIPS 140-2 validated cryptography if you have a choice. I wasn't thinking of standards sabotage at the time; that just reinforces the argument. Unfortunately some OpenSSL users don't have a choice, specifically the ones selling cryptographic products in the USG marketplace. New validations (such as #1747, the latest OpenSSL FIPS Module) are rare. Once done new algorithms can't be added to an existing module, so there is a tendency (ours and the paying sponsors, of which there were dozens) to include everything we think might be relevant over the lifespan of the module (years). So we added a number of new algorithms for that validation (AES-CCM and AES-XTS for instance). The #1747 validation includes more algorithms than any other. Note that Dual EC DRBG is *NOT* used by default and a calling application must specifically and deliberately enable it; that cannot be done accidentally. Any application which does so will hopefully be fully aware of the consequences (and probably must do so for policy reasons). -Steve M. [*]Who was the customer? OSF is bound by some 200 separate NDAs (Non-Disclosure Agreements). Occasionally a client tells us about some product plans or technologies or whatever that they at least consider sensitive and valuable information, but the usual purpose of the NDA is to protect the identity of the client. Acme Corp doesn't want WigitCo to know Acme is using new features in the worlds finest crypto library and toolkit. I don't like NDAs but they are standard practice in the business world and we will honor them. I can say that for damn sure none of my OSF colleagues have implemented any back-doors or deliberate vulnerabilities (other than those inherent in the technical standards themselves). We don't implement features in the baseline code that aren't based on open standards. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
