Algorithms - Part 2 - Suite B and CNSA

Welcome back to our discussion of cryptographic algorithms. We are covering a few of the misunderstood and ambiguous terms used in this category, which brings us to Suite B and CNSA today.

CEO Ray Potter had a great rundown on Suite B here on this very blog in May 2013. Definitely check it out. A lot has happened since then, though. Dual EC DRBG was exposed to be compromised by the NSA, algorithms Simon and Speck were released by the NSA and then scrutinized because they were from NSA, and oh yeah, Suite B itself was phased out!

Suite B used to be NSA’s curated selection of cryptographic algorithms that they deployed for the majority of classified data and sensitive but unclassified information. A very limited subset of classified data was considered important enough to require Suite A encryption, which was the classified set of algorithms not available for commercial use. Does that sound a little bit challenging, to run two highly complex schemes for separate tranches of data? Apparently it was, even for the NSA.

In July 2015, the Committee on National Security Systems (CNSS) issued Information Assurance 02-15, revising a subset of NIST-approved algorithms as NSA-approved and creating the Commercial National Security Algorithm (CNSA) Suite. These algs are generally the same as were used in Suite B, with a few shorter keysize versions deprecated that had previously been used for data deemed SECRET and below:
- ECDH and ECDSA with NIST Curve P-256
- SHA-256
- AES-128
- RSA with 2048-bit keys
- Diffie-Hellman with 2048-bit keys

Under the CNSA Suite, all data is treated with equal cryptographic care, a reflection of the confidence placed in the larger keysize ciphers that have been approved:
- ECDH and ECDSA with NIST Curve P-384
- SHA-384
- AES-256
- RSA 3072-bit or larger
- Diffie-Hellman with 3072-bit or larger

Why the transition to a more simple format, avoiding the differentiation between security clearance levels? I think it’s closely tied to the increased emphasis placed on the Commercial Solutions for Classified (CSfC) effort. CSfC is the program responsible for the advancement of many Commercial off the Shelf (COTS) products in the U.S. federal government. There are regulations, of course, and solutions must still meet compliance checkmarks and jump through hoops, but the concept is one that we support wholeheartedly. Federal agencies are like any other end-user in most ways – custom-built solutions are slower, more expensive, and often unnecessary. Anytime you can deploy an existing product, even if you have to do some configuration to meet specifications, you should do it. The replacement of Suite A and B with the single CNSA Suite is one (significant) configuration issue that no longer has to be addressed.

Interestingly, there have been many caveats issued about the CNSA Suite being essentially a placeholder until quantum resistant crypto has matured to the level of public standardization. This mirrors NIST’s ongoing dialogue with the industry on expectations for quantum. Eventually, a significant shift will occur, but these algorithms will bridge the gap quite nicely for the foreseeable future. 

Since you’re here at the SafeLogic blog, you won’t be surprised to learn that there is significant overlap between CNSA and FIPS 140-2, since both are closely tied to NIST research and publications. AES, of course, is included in both, specified by FIPS PUB 197. (Refer to the last blog post if you haven’t already read about AES.) Digital signatures are covered by FIPS PUB 186-4, approving ECDSA and RSA, while key establishment is governed by NIST SP 800-56, with ECDH in 800-56A and RSA in 800-56B rev. 1. SHA is in FIPS PUB 180-4, leaving the Diffie-Hellman (DH) Key Exchange as the only algorithm in CNSA to not be addressed directly by NIST, leaving it in somewhat of a gray zone for FIPS 140-2. Essentially, as a “non-approved but allowed” algorithm, it can be used if noted as a caveat in the security policy. I know, a ridiculous distinction. So if you are looking for clear-cut compliance for both CNSA and FIPS 140-2 in the same module implementation, stick with ECDH or RSA for key establishment. 

Pretty cool that by limiting yourself to this subset of five algorithms and making sure that all of your parameters meet CNSA minimums, you can meet both requirements. Doesn’t seem that hard, right?

Well, yes and no. It’s more difficult than just asking Siri, but in this case, you can just ask the SafeLogic technical team to help with configuration. So if CNSA is on your radar, or customers are still asking about Suite B, you can explain the transition to them and assure them that your CryptoComply implementation has it completely handled.

Don’t miss the next post, looking at CAVP, the Cryptographic Algorithm Validation Program!