A Crypto Conversation: How We Choose Algorithms

Cryptography is critical to secure, trustworthy communications. Recent questions within the tech industry have created entirely new discussions about the cryptography underpinning our communications infrastructure. While some in the media have focused on the algorithm chosen for Deterministic Random Bit Generation (DRBG), we’ve seen many more look to have a broader crypto conversation. With this backdrop, I’d like to take the opportunity to talk about how we select algorithms (not just the DRBGs) for our products.

Before we go further, I’ll go ahead and get it out there: we don’t use the DUAL_EC_DRBG in our products. While it is true that some of the libraries in our products can support the DUAL_EC_DRBG, it is not invoked in our products. For our developers, the DRBG selection is driven by an internal standard and delivered to those developers from an internal team of crypto experts through a standard crypto library. The DRBG algorithm choice cannot be changed by the customer. Our Product Security Incident Response Team (PSIRT) confirmed this in a Security Response published on October 16.

Like most tech companies, we use cryptography in nearly every product we offer, if only for secure remote management. As a result, we are constantly discussing what algorithms we should support and why—a decision driven by the fact that cryptography is always evolving. Unlike wine, crypto algorithms don’t age gracefully!

We protect our customers and our communications by being active contributors to the crypto ecosystem, inventing algorithms, and participating in industry reviews of new algorithms. As part of these efforts, we interact with a tremendous breadth of people, including standards bodies like IEEE, IETF, ITU, NIST, academia, and, yes, governments from around the world.

When considering cryptographic algorithms for our products, we have three guiding principles:

1. Security of the algorithm — Our own review, external peer review, openness, and “time tested” are all characteristics and processes that go into “secure enough or not” decisions.
2. Interoperability — Given the need to securely talk with other devices on the Internet, we are compelled to ensure that there are interoperable, secure crypto options within our products. As a direct result of customer feedback, we strive to achieve interoperability using international standards. Our customers prefer standards, as they tend to drive openness and royalty-free implementation options.
3. International laws — These laws come in many forms, but for us, they most commonly include U.S. export regulations and country-specific import regulations for crypto-capable products.

Looking back at our DRBG decisions in the context of these guiding principles, we looked at all four DRBG options available in NIST SP 800-90. As none had compelling interoperability or legal implementation implications, we ultimately selected the Advanced Encryption Standard Counter mode (AES-CTR) DRBG as our default. This was because of our comfort with the underlying implementation, the absence of any general security concerns, and its acceptable performance. DUAL_EC_DRBG was implemented but wasn’t seriously considered as the default given the other good choices available.

The DRBG controversy has brought renewed focus on the crypto industry and the need to constantly evaluate cryptographic algorithm choices. We welcome this conversation as an opportunity to improve security of the communications infrastructure. We’re open to serious discussions about the industry’s cryptography needs, what’s next for our products, and how to collectively move forward. In some cases, we are helping to start or lead this discussion.

We will continue working to ensure our products offer secure algorithms, and if they don’t, we’ll fix them. Additionally, we will remain active contributors to the evolution of cryptography in the standards community. These responsibilities are central to our role as a provider of Trustworthy Systems.

Share