Last month, the US National Security Agency (NSA) released the long-anticipated version2.0 of the Commercial National Security Algorithm Suite (CNSA Suite). The CNSA Suite is a suite of algorithms for encryption, signing, and integrity checking that will be required for all “national security systems” (software and hardware that will be run by defense or intelligence agencies).
Most interestingly, the new suite contains only “quantum-resistant” algorithms, which use cryptography that will stand up to cryptanalysis by quantum computers. This comes hot on the heels of NIST’s announcement of the final candidates for standardization in their post-quantum cryptography project, indicating that the US federal government considers quantum computers to be a serious potential threat to existing cryptography.
In this post, we’ll walk you through what the CNSA recommends, and what (if anything) you should do about it.
Background
Why does cryptography need to be “post-quantum” in the first place? The security of the cryptography that encrypts your web traffic rests upon the assumption that certain operations are “hard” for a computer to do. As far as we know, this is true—at least for traditional, “classical” computers. Researchers have proposed “quantum” computers, which use quantum mechanical effects to quickly perform operations on data that would be unnaturally slow on a classical computer. In the 1990s, Peter Shor discovered that a quantum computer could efficiently run an algorithm that would break the most common forms of encryption in use today.
While quantum computers are still the stuff of science fiction, scientists at universities and private corporations have made rapid progress in the past few years. And the NSA doesn’t consider hope to be a strategy: even if the chances that a quantum computer capable of breaking encryption are slight, they don’t want the US to be caught unprepared. Besides, they may know something that we outside of the US Department of Defense don't know about the progress of the field.
See this post on the Sigstore blog for more details.
What’s in the CNSA Suite?
The CNSA Suite contains algorithms for the following settings:
- Symmetric-key encryption.
- Key establishment.
- Digital signing.
- Software and firmware updates.
The algorithms recommended for symmetric-key encryption are the same (SHA2 and AES) as those recommended in the CNSA Suite 1.0, dating to 2015, and in Suite B, dating back to 2005. This shouldn’t come as a surprise to anybody following closely: the primary threat from quantum computers is to asymmetric algorithms, like RSA and elliptic curve Diffie-Hellman; the best known quantum attacks on these algorithms aren’t meaningfully better than the best known classical attacks.
Asymmetric cryptography is where we start to see some new technology. The CNSA Suite recommends CRYSTALS-Kyber and CRYSTALS-Dilithium for key establishment and digital signing, respectively. These algorithms are also candidates for finalization in the NIST post-quantum cryptography process. These algorithms use lattice-based cryptography, which uses fundamentally different mathematics from the cryptography that quantum algorithms can break.
The astute reader might notice that the cryptography used in software and firmware updates is primarily digital signatures.
Why, then, is there a separate category?
There are a few reasons. First, firmware and software updates can be long-lived, so the CNSA Suite recommends more conservative algorithms (Leighton-Micali Signature, or LMS, and Xtended Merkle Signature Scheme, or XMSS). Second, these more conservative algorithms are stateful: they require signers to keep track of how many bytes they’ve signed, and can only be used a fixed number of times. These are unrealistic constraints for many applications, but are reasonable in the context of software updates. Third, keys for verifying updates may be very long-lived (consider a hardware device deployed to a data center and then forgotten), so the CNSA announcement recommends transitioning these systems immediately. The recommended algorithms are better-understood and easier to implement than their lattice-based counterparts.
The announcement also proposes a strategy for transitioning equipment and software to support these new algorithms, and a timeline for such transitions. The timeline is aggressive: vendors should begin supporting these algorithms immediately in order to make these algorithms default by 2030 (or 2025 for software and firmware updates) and use these algorithms exclusively by 2033 (or earlier for software and firmware updates). Considering that there are no production-ready implementations of most of these algorithms available in many popular programming languages and environments, this timeline is quite ambitious.
Takeaways
These recommendations will require different responses from different organizations. The following FAQs will help you figure out what the CNSA means for you.
Q: Do I need to care?
A: If you work in national security or ship products that will be used in national security, definitely: this mandate will be enforced in the next decade, and could be a barrier. Otherwise, you don’t need to care.
Q: Okay, should I care?
A: That’s up to you. If you believe that quantum computers are just hype, then you can just keep doing what you were doing. If you believe that quantum computers will soon be on every desktop, you probably want to get hustling on moving over.
Q: Why now?
A: Without being inside the NSA, we can’t know their exact motivations. The simplest explanation is that NIST’s post-quantum standardization process is starting to conclude, which means that we now have algorithmic recommendations that are independently-vetted: plenty of academics and other external researchers have participated in the NIST contest.
The conspiratorial explanation is that the NSA has an interest in moving encryption over to these algorithms to weaken it. The NSA has been known to manipulate NIST in the past in order to introduce backdoored algorithms. But perhaps the most realistic outcome of this announcement is that the US national security apparatus will implement these algorithms first, followed by other businesses and organizations (domestic and foreign) much later. Given that, recommending weak algorithms might be self-defeating.
Q: I’m convinced! What can I do today to switch to these algorithms?
A: Funny you should ask. These algorithms aren’t in openssl, so it’s not a simple matter of find-and-replace in your code. And if you’re qualified to be implementing these, you probably aren’t reading this FAQ.
The NSA may be hoping to bypass the chicken-and-egg problem here (developers won’t adopt these algorithms until there are good implementations, but nobody will write good implementations until developers demonstrate demand by using these algorithms) with a good old-fashioned government mandate.
Q: That was unhelpful.
A: Not really a question, but point taken.
Realistically, most organizations can get away with following the herd here. Over the next few years, the IETF will put some of these algorithms into TLS, cryptography library authors will implement them, and cloud services will begin offering support. Once these algorithms are offered. If you fall into one of those buckets, you’ll have to start worrying sooner. But just follow the lead of cryptography practitioners and you’ll be safe.
