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
+1 877 673 6775 s/b
+1 301 874 2571 direct
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

Reply via email to