Ok this sounds like Dual EC DRBG is not really a problem for someone not bound to use it. So what about ECDH, I've read in many places e.g. on this cryptography mailinglist [1] that it could be trouble when the curves have been suggested by the NSA. What about the use of hardware rngs?
[1] http://www.mail-archive.com/cryptography@metzdowd.com/msg12325.html On Sat, Sep 7, 2013 at 11:26 PM, Steve Marquess < marqu...@opensslfoundation.com> wrote: > 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 >
