On April 18th, the NSA released an update to their published guidance on national security algorithms, CNSA 2.0 (originally published September 2022). View update here.
This FAQ reinforces the requirement for US National Security Systems (NSS) to be protected on a timeline of transition between 2025 and 2030, and it answers questions based on feedback from stakeholders.
The FAQ includes clarification on some of the latest key topics, including:
- Cryptographic algorithms
- PQ/T hybrid (post-quantum/traditional) schemes
- Stateful HBSS
- Quantum Key Distribution
Some of the key takeaways are as follows:
Included Algorithms
CNSA 2.0 now includes the following:
- AES-256
- ML-KEM 1024
- ML-DSA-87
- SHA-384/SHA-512
- LMS (all parameters allowed, SHA-256/192 recommended but no multitree HSS allowed)
- XMSS (all parameters, no multitree XMSSMT allowed)
With the release of this update, the NSA reinforces its confidence in CNSA 2.0 algorithms, and, having performed its own analysis, confirms that it considers them appropriate for long-term use.
Because of this confidence in the CNSA 2.0 algorithms, the NSA “will not require NSS developers to use hybrid certified products for security purposes.”
While PQ/T hybrids are specifically not recommended in the guidance, the NSA points out that it is not possible to directly replace the CNSA 1.0 public key algorithms with CNSA 2.0 counterparts in IKEv2. They anticipate keeping CNSA 1.0 algorithms as a hybrid layer together with CNSA 2.0 algorithms for key establishment within IKEv2 indefinitely.
Implementation
When it comes to implementation of CNSA 2.0, the NSA expects to be able to provide guidance in collaboration with IETF through the RFC series. RFCs will add detail to protocol options, as well as algorithm choices.
An interesting note is that the FAQ specifies that quantum-safe root-of-trust is a priority, as this approach helps to avoid unexpected costs and later security issues.
Exclusions and clarifications
As it stands, the following algorithms are excluded from CNSA 2.0:
- SLH-DSA
- HSS
- XMSSMT
- SHA-3 (not allowed separately but allowed as part of LMS)
- SHAKE (not allowed separately but allowed as part of LMS)
- ASCON (will not be added to CNSA)
When adopting hash-based LMS or XMSS for software/firmware validation, CAVP testing is all that’s required if your product is only validating signatures. Meanwhile, code signing requires hardware that has been validated by CVMP, or “via other NSA guidance” and the NSA are not granting waivers.
Quantum Alternatives
It’s worth noting that the NSA considers Quantum Key Distribution (QKD) as a highly impractical and inappropriate model for quantum resilience. This theoretical technique uses physics to distribute keys, and is of scientific interest, but is not recommended as an alternative to post-quantum cryptography. NSS owners should not use or research QKD at the current time.
Similarly, consultation with the NSA is recommended before using any cryptography not specified by either CNSA 1.0 or CNSA 2.0. In particular, the following techniques have no approved solutions and should be avoided:
- Distributed ledgers or blockchains
- Private information retrieval (PIR)
- Private set intersection (PSI)
- Identity-based encryption (IBE)
- Attribute-based encryption (ABE)
- Homomorphic encryption (HE)
- Group signatures
- Ring signatures
- Searchable encryption
- Threshold signatures
Conclusion
With this update, the NSA is continuing to encourage vendors and governments to implement CNSA 2.0 algorithms in a way that is primed for NIST standardization. National Security Systems owners need to know the requirements for their systems, and the clarity this update brings is important.
It’s likely that interoperability requirements will require the guidance to be followed by other entities, and will in turn, affect the supply chains of technology vendors.
PQShield’s mission is focused on providing the tools that help upgrade these supply chains to quantum resilience, and it’s encouraging to see the US pointing the way to identifiable, approved solutions. Our products, built with the ethos of PQShield and our world-class team of engineers and cryptographers, are well-positioned for the transition.