Welcome to the Acumen Security Blog

To Suite B or Not to Suite B, That is the Question

Recently, the NSA has updated their Suite B Cryptography webpage: https://www.nsa.gov/ia/programs/suiteb_cryptography/ For Suite B enthusiasts, there is good news and bad news.

First, the good news, in addition to the assortment of AES, SHA, and elliptic curve algorithms included in the Suite B specification, the NSA has added some additional algorithm alternatives to elliptic curves. These options include the following:

  • Diffie-Hellman (DH) Key Exchange for key establishment: Minimum 3072-bit modulus to protect up to TOP SECRET
  • RSA for key establishment (i.e., key wrapping): Minimum 3072-bit modulus to protect up to TOP SECRET
  • RSA for digital signatures: Minimum 3072-bit modulus to protect up to TOP SECRET

This potentially makes Suite B support easier for many product vendors since the elliptic curve algorithms are the ones most commonly not supported. Now, for the bad news! As part of the website update, the NSA has also included the following statement,

IAD recognizes that there will be a move, in the not distant future, to a quantum resistant algorithm suite. Based on experience in deploying Suite B, we have determined to start planning and communicating early about the upcoming transition to quantum resistant algorithms……. For those partners and vendors that have not yet made the transition to Suite B algorithms, we recommend not making a significant expenditure to do so at this point but instead to prepare for the upcoming quantum resistant algorithm transition.

It seems that just as Suite B was getting started, the NSA has already started moving toward the next generation of cryptography. In fact, they are recommending that if you haven’t started implementing Suite B that you shouldn’t spend a ton of time and money doing so.

Now, this brings a number of questions to mind, such as,

  • Will the revision to CNSSP-15 mentioned on the web page ease or eliminate the requirement that “IA and IA‐enabled IT products with integrated cryptography acquired to protect NSS and information therein shall adhere to…the appropriate Suite B cryptographic algorithms” starting in October?
  • Will certification programs that base functional requirements off of Suite B, such as, CSFC, change or eliminate their requirements to reflect the new statements on Suite B?
  • Will RFCs based on Suite B compliance, such as, RFCs 6239, 6460, and 6380 be updated to reflect the new algorithms?

We at Acumen are actively investigating the impact of this change and will keep you up to date as we get additional information. As a reminder, check out our previous blog regarding how Suite B applies to commonly certified protocols, such as, TLS, SSH, IPsec: https://blog.acumensecurity.net/fips-validated-but-does-it-support-suite-b/

P.S.: Sincerest apologies to The Bard for the title but it seemed apropos :)

UPDATE 8/26/2015:

Update: Based on Investigation

Based on several conversations Acumen has had over the last week, we have come to the following understandings:

IAD is not asking vendors to stop implementing the Suite B algorithms and is not asking national security customers to stop using these algorithms. The motivation of the policy updates are actually to give more cryptographic flexibility to vendors and government users as IAD prepares for the advent of quantum cryptography. [Note: This is consistent with what we initially identified with the inclusion of the RSA alternatives to ECC.]

IAD customers using layered commercial solutions to protect classified national security information with a long intelligence life should begin implementing a layer of quantum resistant protection. Such protection may be implemented today through the use of large symmetric keys and specific secure protocol standards.

As we find out more information, we will update our blog to keep you up to date.

Time to comment on FIPS 140-NEXT

The time has come to provide comments on the proposed successor to FIPS 140-2. NIST has put a proposal for comment to use ISO 19790 as the next revision of FIPS 140 (we like to call it FIPS 140-NEXT but it will probably end up being called FIPS 140-3). The link to the request for comments can be found on Federal Register, here:

https://www.federalregister.gov/articles/2015/08/12/2015-19743/government-use-of-standards-for-security-and-conformance-requirements-for-cryptographic-algorithm

As a reminder, we performed an analysis comparing FIPS 140-2 to ISO 19790. You can find our original here: https://blog.acumensecurity.net/getting-ready-for-an-iso-19790-based-fips-140-next/

We here at Acumen will be providing comments both on the content of ISO 19790 and the usage of it as the next version of FIPS 140. What do you are all think? Will you be commenting on the proposal?