Recently, the NSA (re-published?) their CNSA guidelines and some information on post-quantum computers (per the title of the document).

Here's the link for convenience (document is titled, 'Quantum Cryptography and Post-Quantum Computing' if you'd rather not go straight to the link)

Question about P-256 Removal

The noticeable difference in the new suite is that, at a minimum, EC-384 strength keys are recommended. Reading through the document, it appears these standards are not just for the public sector or private contractors handling classified documents, but rather everyone (public and private).

For example, one the posed questions on their sheet is, "The data I have on my particular NSS only requires protection for a short time. Do I really need to comply with the increased algorithm strengths of CNSSP-15?" (keeping in mind the only 'increase' in strength here was via dropping SHA-256 & EC-384).

The answer given to that question was, "NSA mandates transitioning algorithms for NSS in order to conform to a common standard and to ensure interoperability. NSS developers and operators should transition to comply or consult with NSA about the issues involved in their specific scenario."

I take this to effectively mean that at the time they published that, EC-256 & SHA-256 are to be considered dead in the water.

I pulled up the NIST SP 800-56A Rev3 to gather more information and that document essentially states that even unclassified data seems to be a no-go when it comes to curves below EC-384.

They state, "D/As planning to deploy ECC with P-256 likely require a further change (e.g., to P-384) before quantum-resistant algorithms reach sufficient market penetration." They state that the intent is to avoid as many "hops" as possible(?), then finish by stating, "Therefore, D/As planning to deploy ECC with curves other than P-384 to protect UNCLASSIFIED NSS or to provide community of interest separation consult with NSA before proceeding."

This blog post by 'Atsec Security' suggests that the transition needs to be made and completed by September 2021 (just passed).

Verdict on Other Structures Relying on 128-bit Strength Crypto

Obvious examples here start with Bitcoin and all cryptocurrencies. Bitcoin uses secp256k1 & SHA-256. Since Bitcoin just topped a valuation of $1 trillion today, one can assume that if there is any cryptanalytic method that someone has found that is within the realm of practical (i.e., can crack at least one key within a year, maybe; I don't know, that's over my head), then this entire protocol is in trouble.

Would you all agree or disagree? And if you disagree, why? Also, Cloudflare has been issuing certificates that are default EC-256 / SHA-256 strength for some time. Can the connection to those sites still be considered secure?

I wanted to come here first to hear from the experts before spreading any disinformation / panic elsewhere.

  • 1
    $\begingroup$ Nope! If EC-256 has been insecure now, pretty sure, ec-512 will go soon, too. About SHA-256, I'm very skeptical since the NIST security levels are not really realistic then; the Brassard et al. requires a huge amount of quantum memory to be faster than Grover. And, is about the NIST curves those are already unsafe according to real cryptographers. Poor NIST, must stay with their curves. $\endgroup$
    – kelalaka
    Commented Oct 7, 2021 at 8:06
  • 1
    $\begingroup$ "A: SHA-384 support was included in previous versions of CNSSP-15 and it is judged to provide sufficient security for NSS. For interoperability purposes, the selection of a single hash function has been maintained in the CNSA Suite. NSA does not anticipate revisiting this decision until the post-quantum algorithm transition." That's not the same as burning down SHA-256. $\endgroup$
    – Maarten Bodewes
    Commented Oct 7, 2021 at 12:30
  • $\begingroup$ There is discussion about how much security SHA-256 provides , which gets complicated when you factor in time / resource considerations. You can certainly argue that it is less than 128 in specific circumstances, but nowhere near practically breakable - even if you include quantum computers in the mix. Of course, if you have the option then you can always decide to use SHA-384 (or -512) and avoid even the discussion. As you can see, even NSA however allows for SHA-256 in e.g. certificates in many instances (but they also seem to blanket-allow RSA-2048, so there's that). $\endgroup$
    – Maarten Bodewes
    Commented Oct 7, 2021 at 12:32
  • 3
    $\begingroup$ The SafeCurves page is an advertisement for Edwards and Montgomery curves. It might be ok to use it to persuade engineers or product managers to support Curve25519, but I would recommend against mentioning it in a serious discussion about security, especially among “real cryptographers”. It contains a number of claims that are misleading or outdated from a technical standpoint. $\endgroup$ Commented Oct 8, 2021 at 6:57
  • $\begingroup$ This is not recent. As stated on p3 of the Q&A you link, CNSSP-15 in 2016 created CNSA by removing SHA-256 and P-256 from the former Suite B and adding RSA and FFDH 3072. NIST 800-56A rev 3 says nothing about dropping P-256; the statement in that blog "submissions under FIPS 140-2 are only allowed up to September 2021" is because 140-2 was superseded by 140-3 two years ago and 140-3 continues to accept both SHA-256 and P-256. ... $\endgroup$ Commented Jul 20, 2022 at 19:37

1 Answer 1


NSA removed EC-256 and SHA-256 from CNSA recently--should we be alarmed by this?


There is one overwhelming reason why, as stated in the document:

The cryptographic systems that NSA produces, certifies, and supports often have very long lifecycles. NSA has to produce requirements today for systems that will be used for many decades in the future, and data protected by these systems will still require cryptographic protection for decades after these solutions are replaced.

NSA standards and NIST standards for "industry" are not the same from an implementation perspective, if you want your web server to start using a 512-bit curve instead of 256, you may need to upgrade openssl, but usually it only takes less than a day to make the change once authorized. An NSA certified hardware device used by operatives in deep cover on the other hand, not nearly so easy to replace. Also milspec radios, satellite communications, comm hardware installed in a submarine.... none of those are replaced often and may have more than a decade of testing after design is complete. Same thing with key rotation intervals, and the amount of time data may need to remain confidential, all much longer for national security.

With the "industry" sun-setting of security levels below 128-bits in about 8 years, and perhaps levels below 160 bits a decade later, doing the math you can imagine that NSA standards may require about 2 decades of security beyond industry... and this is in fact mentioned in the document:

New cryptography can take 20 years or more to be fully deployed to all National Security Systems.

So now it makes perfect sense, they are simply trying to be ahead of the already well documented and understood trends regarding key sizes for use in the future, but need to act NOW because of the long timeframes involved in validating, purchasing, and replacing new hardware and software.

Dropping SHA-256 for SHA-384 can be seen as logical for several reasons. The first and foremost, you MUST use a 384-bit curve or larger, second is performance on 64-bit platforms, and third is it shares a common code base with the larger SHA-512 for asymmetric implementations still targeting 256-bit security.

So that brings us back to dropping of P-256... is that a big deal at this point? In 2041, 20 years from now, it certainly won't be, and that is why we should NOT be alarmed in the slightest, I would expect 160-bit security to be the minimum, even for low security civilian applications. For AES now that means 192-bits or larger, with a matching 384-bit signature scheme, and that is what is specified in the document.

If you recall the AES competition, the target lifespan was until 2030, so it may be the case that in 2041, we will already be using a fancy new block cipher from another competition. Of course, AES has held up extremely well to practical attacks on its mathematics.

Reading through the document, it appears these standards are not just for the public sector or private contractors handling classified documents, but rather everyone (public and private).

Not really, this is specifically in regards to commercial products implementing encryption for use by the US government, that implement non-classified algorithms from the CNSA suite. Commercial here can mean off the shelf, or developed by a contractor to fulfill a government requirement. These products still must be validated using other criteria, but they must implement the listed algorithms while NOT implementing algorithms that do not need the minimum security requirement (citation needed on that one), though they may still implement the Suite B algorithms with strong security, at least for now.

So focus instead on how the document engages the quantum threat: Use symmetric algorithms or wait until the CNSA suite is updated with quantum resistant asymmetric algorithms (almost certainly lattice based) after NIST publishes a draft standard, sometime between next year and 2024.

If they were really freaking out about quantum attacks, it would be because they themselves had developed a practical attack, and were concerned China/Russia/Iran would not be far behind, and would be taking drastic steps at great expense.

I pulled up the NIST SP 800-56A Rev3 to gather more information and that document essentially states that even unclassified data seems to be a no-go when it comes to curves below EC-384.

Where do you see that? Under Table 24: Approved elliptic curves for ECC key-agreement., even 224-bit curves and 2048-bit prime groups are still listed, though they are very clear about the targeted security strength. It just so happens that CNSA cherry pics the algos that meet their security, implementation, flexibility, and interoperability requirements.

The NIST standards are more about saying you are allowed to use this now, and the NSA doc is more about what you are allowed to start using now, there is overlap but purpose is very different, nothing seems out of the ordinary, in fact I would consider NOT mandating larger key sizes than given in the doc to be the most telling about how we should not panic... so don't panic.

  • $\begingroup$ “the "industry" sun-setting of security levels below 128-bits in about 8 years” depends a lot on what industry one is looking at. Some industries like access control should be sunsetting 48-bit symmetric crypto and 1024-bit RSA/Rabbin. $\endgroup$
    – fgrieu
    Commented Oct 8, 2021 at 5:51
  • $\begingroup$ @fgrieu indeed, by industry I am referring to public sector companies actually following the guidelines set in SP800-131A and SP800-57(1) $\endgroup$ Commented Oct 8, 2021 at 6:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.