Notified: November 06, 2013 Updated: November 07, 2013
Not Affected
No statement is currently available from the vendor regarding this vulnerability.
We are not aware of further vendor information regarding this vulnerability.
Notified: October 03, 2013 Updated: November 07, 2013
Not Affected
Cisco Response Cisco is aware of the industry discussion regarding the Dual Elliptic Curve Deterministic Random Bit Generator (Dual_EC_DRBG) and the recent decision of the U.S. National Institute of Standards and Technology (NIST) to reopen the 800-90A Special Publication (SP) to public review. Cisco applauds the decision for increased public review of cryptographic standards and will monitor for any updates to NIST SP 800-90A. Cisco has completed an internal investigation and has confirmed that the Dual_EC_DRBG is not in use in any Cisco products. Additional Information Cisco licenses third-party components that include the Dual_EC_DRBG; however, this Deterministic Random Bit Generator (DRBG) is not in use in any Cisco products. Cisco products that use DRBGs for encryption are compliant with either the older ANSI X9.31 standard or the newer NIST SP 800-90A standard. The 800-90A-compliant crypto libraries in Cisco products have four DRBG options available to Cisco developers, but the standard Cisco implementation is Advanced Encryption Standard Counter mode (AES-CTR), not Dual_EC_DRBG. Additionally, there are no configuration modifications that could enable Dual_EC_DRBG. Cisco provides strong encryption options that comply with international standards and local regulations. We are always watching for stronger encryption options, and if we find such an option, it will be implemented for the benefit of our customers. Status of this Notice: Final THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors.
We are not aware of further vendor information regarding this vulnerability.
Notified: October 08, 2013 Updated: October 16, 2013
Not Affected
"The DUAL_EC_DRBG is disabled in all releases; it is not selectable by any configuration options on our products, and is not utilized in any compatibility modes either."
DUAL_EC_DRBG is disabled and not user selectable in all software.
Notified: October 03, 2013 Updated: November 07, 2013
Not Affected
"Due to recent statements (top of page #2) by the US National Institute of Standards and Technology (NIST) concerning the security of the Dual_EC_DRBG cryptographic algorithm, Juniper Networks would like to make the following statements: The following product families do not utilize Dual_EC_DRBG: Junos - Any product running Junos Junos Pulse Secure Access Service (SSL-VPN / IVE OS) Junos Pulse Access Control Service (UAC) Junos Pulse Junos Space JunosE CTP/CTPView The following product families do utilize Dual_EC_DRBG, but do not use the pre-defined points cited by NIST: ScreenOS* * ScreenOS does make use of the Dual_EC_DRBG standard, but is designed to not use Dual_EC_DRBG as its primary random number generator. ScreenOS uses it in a way that should not be vulnerable to the possible issue that has been brought to light. Instead of using the NIST recommended curve points it uses self-generated basis points and then takes the output as an input to FIPS/ANSI X.9.31 PRNG, which is the random number generator used in ScreenOS cryptographic operations."
We are not aware of further vendor information regarding this vulnerability.
Notified: October 07, 2013 Updated: December 09, 2013
Not Affected
Lancope's products do not enable Dual_EC_DRBG by default. For those customers who have taken the extra step of enabling Dual_EC_DRBG, Lancope has provided guidance to our user community regarding how to enable alternatives. If you are a Lancope customer in need of guidance information, please contact technical support.
We are not aware of further vendor information regarding this vulnerability.
Notified: October 03, 2013 Updated: March 25, 2014
Affected
"On September 17, 2013 an Edward Snowden leak indicated that the NSA may have a skeleton key to decrypt messages using the Dual Elliptic Curve (EC) Deterministic Random Bit Generation (DRBG) algorithm in RSA’s BSafe library. This was followed by NIST reopening SP800-90 due to some concerns the community has regarding the security of the DUAL_EC_DRBG algorithm. The RSA BSafe crypto libraries are widely used for C, C++, and Java based programs used by many vendors, including McAfee. The libraries are also certified as FIPS 140-2 thus providing an avenue to certifying products as directed by NIST. Impact: Currently, McAfee has three (3) products that use Dual EC DBRG, and thus, are vulnerable. Vulnerability Manager for Databases (DVM) / Database Activity Monitoring (DAM) Network Security Management (NSM) appliances McAfee Firewall Enterprise Control Center (MFE CC) NOTE: MFE CC uses the CryptoJ BSAFE and Dual EC DRBG in FIPS mode only. Customers who do not run in FIPS mode never use Dual EC DRBG. The use of Dual EC DRBG was removed in 5.3.2 This issue is resolved in each of the vulnerable products per the release schedule in the Remediation section of this article."
Notified: October 03, 2013 Updated: November 07, 2013
Not Affected
No statement is currently available from the vendor regarding this vulnerability.
We are not aware of further vendor information regarding this vulnerability.
Notified: October 10, 2013 Updated: November 07, 2013
Not Affected
The Dual_EC_DRBG algorithm was one of three random number generators made available to developers as options in DSF, NanoCrypto, and related products. All DSF components, including NanoCrypto, default to using FIPS 186 pseudorandom number generation, NOT Dual_EC_DRBG. The flawed Dual_EC_DRBG algorithm is available as an option in our DSF SDKs, and your developers may have “turned it on” at build time, overriding the Mocana default selection of FIPS 186; or they may have explicitly called the ECDRBG engine. If neither of these two steps were taken, then the random number generation algorithm used is not the compromised Dual_EC_DRBG.
We are not aware of further vendor information regarding this vulnerability.
Notified: October 03, 2013 Updated: October 16, 2013
Not Affected
"The OpenSSL FIPS module is a cryptographic module which has been put through FIPS 140-2 testing. It is completely separate from OpenSSL itself. If certain versions of OpenSSL are linked against that module they become "FIPS capable" and redirect cryptographic operations to the OpenSSL FIPS module. If OpenSSL is not linked against the FIPS module the DUAL_EC_DRBG is not available at all. The DUAL_EC_DRBG is not used by default in any versions of OpenSSL. It is implemented in the current version of the OpenSSL FIPS module but the FIPS capable versions of OpenSSL will not use it by default. Specific calls need to be made to use the DUAL_EC_DRBG: i.e. it cannot be used "by accident". In other words unless the application makes very specific calls to enable the DUAL_EC_DRBG it will never be used."
Only the OpenSSL FIPS module implements DUAL_EC_DRBG but it is not enabled by default. The standard distributions of OpenSSL do not utilize DUAL_EC_DRBG.
Notified: October 16, 2013 Updated: October 16, 2013
Unknown
No statement is currently available from the vendor regarding this vulnerability.
Notified: October 03, 2013 Updated: February 18, 2014
Affected
No statement is currently available from the vendor regarding this vulnerability.
We are not aware of further vendor information regarding this vulnerability.
http://jeffreycarr.blogspot.com/2014/01/blackberry-ltd-nsa-and-encryption.html
Notified: September 23, 2013 Updated: October 16, 2013
Affected
"Due to the debate around the Dual EC DRBG standard highlighted recently by the National Institute of Standards and Technology (NIST), NIST re-opened for public comment its SP 800-90 standard which covers Pseudo-random Number Generators (PRNG). For more information about the announcement see: http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-90-A%20Rev%201%20B%20and%20C The ITL Security Bulletin mentioned in this announcement includes the following: “Recommending against the use of SP 800-90A Dual Elliptic Curve Deterministic Random Bit Generation: 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.” The currently released and supported versions of the BSAFE libraries (including Crypto-J 6.1.x and Crypto-C ME 4.0.x) and of the RSA DPM clients and servers use Dual EC DRBG as the default PRNG, but most libraries do support other PRNGs that customers can use. We are providing guidance to our customers on how to change the PRNG from the default in their existing implementation. In the current product documentation, RSA has provided technical guidance for RSA BSAFE Toolkits and RSA DPM customers to change the PRNG in their implementation. RSA will change the default RNG in RSA BSAFE Toolkits and RSA DPM as appropriate and may update the algorithm library as needed."
We are not aware of further vendor information regarding this vulnerability.
Notified: October 08, 2013 Updated: October 16, 2013
Not Affected
"Dual EC DRBG is one of many algorithms available for use within CryptoComply for Mobile and CryptoComply for Server modules, but requires specific customer action to select and activate the algorithm in question. Our default is AES 256 CTR, which is covered in Section 10.2 of SP 800-90A."
CryptoComply for Mobile and CryptoComply for Server modules do not utilize DUAL_EC_DRBG by default. The algorithm is implemented but requires user action to select and enable.
Notified: October 03, 2013 Updated: October 03, 2013
Unknown
No statement is currently available from the vendor regarding this vulnerability.