Vulnerability Note VU#274923

Dual_EC_DRBG output using untrusted curve constants may be predictable

Original Release date: 07 Nov 2013 | Last revised: 25 Mar 2014


Output of the Dual Elliptic Curve Deterministic Random Bit Generator (DUAL_EC_DRBG) algorithm may be predictable by an attacker who has chosen elliptic curve parameters in advance.


NIST SP 800-90A defines three elliptic curves for use in Dual_EC_DBRG but does not describe the provenance of the parameters used to define the curves. Noted cryptographers and cryptographic vendors have expressed concern that an attacker who has carefully chosen parameters used to define the curves could predict the output of Dual_EC_DBRG. Due to these concerns, and since Dual_EC_DRBG is an approved Federal Information Processing Standard (FIPS), NIST has reopened Special Publication 800-90 for comment. The CERT/CC has contacted vendors that are identified by NIST as being FIPS-certified Dual_EC_DRBG implentors. We have included their responses below and in the Vendor Information section.

This issue is an instance of CWE-327: Use of a Broken or Risky Cryptographic Algorithm.

Dual_EC_DRBG is also specified in ISO/IEC 18031:2011 Information technology -- Security techniques -- Random bit generation.

NIST explains the issue in a bulletin:

    Concern has been expressed about one of the DRBG algorithms in SP 800-90/90A and ANS X9.82: the Dual Elliptic Curve Deterministic Random Bit Generation (Dual_EC_DRBG) algorithm. This algorithm includes default elliptic curve points for three elliptic curves, the provenance of which were not described. Security researchers have highlighted the importance of generating these elliptic curve points in a trustworthy way. This issue was identified during the development process, and the concern was initially addressed by including specifications for generating different points than the default values that were provided. However, recent community commentary has called into question the trustworthiness of these default elliptic curve points.

CERT/CC is not aware of any demonstrated or reported attacks against applications of Dual_EC_DRBG.

Based on responses from vendors and publicly available information, the following vendors do not use DUAL_EC_DRBG in their products:
  • Cisco
  • Catbird Networks

The following vendors do use DUAL_EC_DRBG in their products, but it is not enabled by default:
  • Blackberry
  • Cummings Engineering
  • Juniper (only in ScreenOS)
  • Lancope
  • McAfee
  • Microsoft
  • Mocana
  • OpenSSL (only in the FIPS module)
  • SafeLogic

The following vendors do use DUAL_EC_DRBG in their products, and it is enabled by default:
  • RSA

Further details for each vendor are available in the Vendor Information section below.


A remote, unauthenticated attacker with minimal knowledge of the vulnerable system and the ability to conduct a brute force attack against an affected application may be able to guess secret key material. Secondary impacts include authenticated access to the system through the affected service or the ability to perform man-in-the-middle attacks.


Apply an Update

Some of the vendors listed have provided an update:

Discontinue use of Dual_EC_DRBG

The NIST bulletin recommends organizations discontinue use of the algorithm until its security concerns are mitigated:
    NIST strongly recommends that, pending the resolution of the security concerns and the re-issuance of SP 800-90A, the Dual_EC_DRBG, as specified in the January 2012 version of SP 800-90A,no longer be used.

There are several other DRBG algorithms available for generating random numbers, including those based on hash functions and block ciphers. Utilizing one of those algorithms will mitigate the risk of this vulnerability.

Generate elliptic curves with known provenance
While not compatible with FIPS specifications, generating your own elliptic curves will provide assurance that random numbers cannot be predicted. See section A.2 of Appendix A in NIST SP 800-90A for more information.

Regenerate key material
Due to the nature of the flaw, any key material generated using Dual_EC_DRBG should be considered insecure. After changing algorithms or generating new curves, the key material must be regenerated. Vendor-specific instructions for doing this can also be found in the Vendor Information section of this document.

Vendor Information (Learn More)

VendorStatusDate NotifiedDate Updated
McAfeeAffected03 Oct 201325 Mar 2014
Research in Motion (RIM)Affected03 Oct 201318 Feb 2014
RSA Security, Inc.Affected23 Sep 201316 Oct 2013
CatBirdNot Affected06 Nov 201307 Nov 2013
Cisco Systems, Inc.Not Affected03 Oct 201307 Nov 2013
Cummings EngineeringNot Affected08 Oct 201316 Oct 2013
Juniper Networks, Inc.Not Affected03 Oct 201307 Nov 2013
LancopeNot Affected07 Oct 201309 Dec 2013
Microsoft CorporationNot Affected03 Oct 201307 Nov 2013
MocanaNot Affected10 Oct 201307 Nov 2013
OpenSSLNot Affected03 Oct 201316 Oct 2013
SafeLogicNot Affected08 Oct 201316 Oct 2013
PanzuraUnknown16 Oct 201316 Oct 2013
SafeNetUnknown03 Oct 201303 Oct 2013
If you are a vendor and your product is affected, let us know.

CVSS Metrics (Learn More)

Group Score Vector
Base 7.1 AV:N/AC:H/Au:N/C:C/I:C/A:N
Temporal 5.2 E:U/RL:W/RC:UC
Environmental 1.8 CDP:MH/TD:L/CR:H/IR:H/AR:ND



Dan Shumow, Niels Ferguson (2007) and Daniel Brown (2006) published information related to this issue.

This document was written by Chris King.

Other Information

  • CVE IDs: CVE-2007-6755
  • Date Public: 21 Aug 2007
  • Date First Published: 07 Nov 2013
  • Date Last Updated: 25 Mar 2014
  • Document Revision: 53


If you have feedback, comments, or additional information about this vulnerability, please send us email.