
DRBG Validation List - lawnchair_larry
http://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgval.html
======
tptacek
A couple random observations:

* The overwhelming majority of vendors here list Dual_EC_DRBG along with the HMAC and CTR DRBGs. A reminder: Dual_EC is a catastrophically slow CSPRNG that relies on bignum multiplication; if you pay any attention to crypto performance at all, you have every incentive never to use Dual_EC, and to an almost reasonable first approximation, _nobody_ does. The HMAC and CTR CSPRNGs are innocuous designs based on simple conventional crypto.

* I'm a little suspicious of this list because it suggests Windows Server 2008 and Windows 7 use only Dual_EC. Neither do; you'd have to go through contortions to make Windows use Dual_EC. Obviously, the list is about certifications and not actual field configurations, but still, you should know: Windows does not rely on Dual_EC.

* Here are the products (other than Windows, which, see above) that are listed as only certifying Dual_EC:
    
    
        Lancope
        Mocana
        McAfee Firewall Console
        Thales Datacryptor
    

None of these are particularly important industry products. McAfee is not a
leading firewall vendor (Cisco and Juniper are). Lancope is a niche intrusion
detection product, and Lancope is not exactly a hotbed of cryptographic
research, if you get my drift. Also, the CSPRNG Lancope would be using would
be relevant only to their admin console. I don't know what Mocana or Thales
do, which could be my ignorance showing, or it could be telling given what I
do for a living.

Here's what Bruce Schneier had to say about the Dual EC DRBG:

 _" If this story leaves you confused, join the club. I don't understand why
the NSA was so insistent about including Dual_EC_DRBG in the standard. It
makes no sense as a trap door: It's public, and rather obvious. It makes no
sense from an engineering perspective: It's too slow for anyone to willingly
use it. And it makes no sense from a backwards-compatibility perspective:
Swapping one random-number generator for another is easy."_

This is basically my take on Dual EC as well. I am _not putting it past the
NSA to backdoor a crypto standard_ (I would bet against it being a NIST
standard --- if they backdoored a standard, my money is on a telephony/RF one
--- but I would not bet my house against it). But this would be an
inexplicable backdoor to add.

~~~
makomk
For definitions of "nobody" that include essentially all of RSA Security Inc's
crypto libraries and a number of their other products, at least by default -
and how many people are going to change the default?

~~~
healsjnr1
To be honest, nearly every developer will change it from the default as soon
as they run a stress or performance test using a library that has dual ec as
its default (e.g. BSAFE Crypto-J).

Dual EC is order of magnitudes slower than HMAC. It's impossible to not notice
a default EC library if you run any kind of throughput test. Then, unless you
a specific requirement to use it, you change the default.

------
lawnchair_larry
This is the only place that I've been able to find a decent list of vendors
potentially affected. This lists _all_ vendors, so you will have to ctrl-f for
BSAFE.

To be completely clear, most vendors on this list are _not_ known to be
affected, only those listed as using the library, or libraries derived from it
(also listed).

All entries using Dual_EC_DRBG are _potentially_ affected, but it is believed
that most do not use that by default. If it's the only one listed, you can
probably assume they use it by default. Especially things called "Datacryptor
DUAL_EC_DRBG" by Thales e-Security.

~~~
eli
This seems dangerous. If you're going to name and shame people, I think you've
really got to be extremely sure you're naming the right people.

~~~
DerpDerpDerp
This isn't an article naming-and-shaming; it's an information dump so people
can sort through it and find the right people to actually name-and-shame.

~~~
ballard
This lists which companies have certified implementations, not which products
relies on which CSPRNG/s by default. I think there are already internal code
audits underway by some of the listed entities, if not, it would be wise to
get started real quick before customer anger arrives.

If this is not a clear impetus for open source, eg, publicly audit-able code
>>> trade secrets, I think we should keep blindly accepting black box
solutions, from chip to app. No funny business ever happens without
transparency.

------
jlgaddis
I've got dozens of pieces of Cisco gear deployed throughout my network but I'm
far from a crypto expert and, honestly, haven't really kept up on this
specific issue so perhaps somebody can help me out here.

Within Cisco's operating systems (primarily IOS, but also NX-OS, IOS XR, etc.)
I can think of a number of places where hashing and encryption are used:
password hashes (obviously), BGP passwords, OSPF authentication, NTP secret
keys, etc. Which of these might potentially be affected if Cisco were using
this algorithm? Any of them? All of them? With the exception of being able to
specify particular types of hashes for user passwords, I'm not sure what else
one might do to mitigate any vulnerabilities.

 _Edit: After thinking about it for a few minutes, I realized that since the
processors in Cisco devices are already so slow (relatively speaking), Cisco
would likely avoid using such an algorithm when other, much faster options are
available. I can 't be for sure, of course, but it seems reasonable. In the
meantime, I'll keep my tinfoil hat on._

~~~
tptacek
It would be shocking if Cisco were using Dual_EC in any "traffic-scale" crypto
in their devices. It isn't just extremely slow, but also slow in a way that
makes it obnoxious in embedded environments.

~~~
lawnchair_larry
[https://supportforums.cisco.com/thread/2062466](https://supportforums.cisco.com/thread/2062466)

[http://www.juniper.net/security/auto/vulnerabilities/vuln241...](http://www.juniper.net/security/auto/vulnerabilities/vuln24104.html)

[https://latinamerica.rsa.com/rsasecured/product.aspx?id=968](https://latinamerica.rsa.com/rsasecured/product.aspx?id=968)

 _" Cisco routers utilize RSA BSAFE encryption and are certified to
interoperate with RSA Certificate Manager software and RSA SecurID
authentication technology."_

You're shocked now, I guess.

But it's no big deal, nobody uses Cisco routers.

Throw Novell in there too:

[http://www.novell.com/support/kb/doc.php?id=3590033](http://www.novell.com/support/kb/doc.php?id=3590033)

and Adobe:

[https://latinamerica.rsa.com/rsasecured/product.aspx?id=108](https://latinamerica.rsa.com/rsasecured/product.aspx?id=108)

and many more:

[https://latinamerica.rsa.com/rsasecured/results.aspx?search=...](https://latinamerica.rsa.com/rsasecured/results.aspx?search=bsafe)

~~~
tptacek
Do any of those products actually use Dual_EC? Have you checked?

~~~
tptacek
You really think iOS has its IPSEC primitives wired directly to Dual_EC?
That's what that error message suggests. It's not subtly slower; it's like
doing an RSA operation on _every damn packet_.

------
Nanzikambe
Wow, the scale of this is amazing, virtually all versions of windows are
affected (search "Microsoft Corporation" & check for "Dual_EC_DRBG") as are a
substantial number of Cisco products.

Apple seems to fare better assuming that's what this means: CTR_DRBG: [
Prediction Resistance Tested: Enabled;

Regarding hardware devices (Cisco etc routers) it'd be interesting to get an
audit of vulnerability by firmware versions. People are terrible at keeping
those things up to date.

TL'DR: if you fear MITM, you've got your work cut out auditting your
infrastructure

~~~
tptacek
Microsoft _implements_ Dual_EC, but does not default to it.

CTR_DRBG is just a block cipher in counter mode. I don't think it's a scary
construction.

~~~
marshray
I SAW THAT TPTACEK SAYS CTR MODE IS NOT A SCARY CONSTRUCTION!

Oh you are never going to live that down brother :-)

~~~
tptacek
IN A RANDOM NUMBER GENERATOR.

I am not terrified of CTR, by the way; I just think CBC gets a bad rap. It's
interesting that people can be on a jihad against DSA for needlessly depending
on randomness, but not at all perturbed by the CTR randomness failure mode.

(Granted, the DSA failure mode is much worse and much harder to get right.)

~~~
marshray
And why is it OK for use in a PRNG/DRBG and not a cipher?

~~~
fleitz
Because generally the plaintext input to a PRNG using a cipher in CTR mode is
uninteresting to attackers, and generally cannot be controlled. What a DRBG
needs to do is provide unpredictable bits, not bits that can't be decrypted.

~~~
marshray
If the "plaintext input to a PRNG" becomes known to the attacker, the entire
output of the PRNG becomes known (i.e., 'predictable') to the attacker.

~~~
fleitz
That's why I try not to give attackers root access to the system, that way
they can't examine the state of my PRNG.

------
marshray
Let's be clear here: This is a list of product that NIST considers "validated"
by an accredited lab for one or more of their SP800-09 DRBGs.

Only the "Dual EC" DRBG is known to be weak/backdoored.

We know that some of them do, but just because a product contains a validated
Dual EC DRBG doesn't mean it's on by default.

Basically, the only reason to use such a DRBG is FIPS compliance, and since
FIPS mandates so many other odd things most product has a special "FIPS mode"
switch which is off by default.

~~~
tptacek
Is it even known to be weak? Or is it, like P-224 and P-256 themselves, simply
based on a constant that we don't know the provenance of?

~~~
marshray
Yes, once the spec was released it was immediately found to have biases.

------
jlgaddis
Hmm, interesting to see Harris Corporation is on the list. They provide __a
lot __of encryption gear to the U.S. government.

