National Security Agency | Cybersecurity Advisory

Announcing the Commercial National Security
Algorithm Suite 2.0
Executive summary
The need for protection against a future
deployment of a cryptanalytically
relevant quantum computer (CRQC) is
well documented. That story begins in
the mid-1990s when Peter Shor
discovered a CRQC would break
public-key systems still used today. Continued progress in quantum computing research
by academia, industry, and some governments suggests that the vision of quantum
computing will ultimately be realized. Hence, now is the time to plan, prepare, and
budget for an effective transition to quantum-resistant (QR) algorithms, to assure
continued protection of National Security Systems (NSS) and related assets.
This advisory notifies NSS owners, operators, and vendors of future requirements for
QR algorithms for NSS. These algorithms (also referred to as post-quantum algorithms)
are analyzed as being secure against both classical and quantum computers. They are
an update to those in the Commercial National Security Algorithm Suite (referred to as
CNSA 1.0, the algorithms currently listed in CNSSP 15, Annex B). NSA will reference
this update as CNSA Suite 2.0, and any future updates will modify the version number.
NSA is providing this advisory in accordance with authorities detailed in NSD-42, NSM8, NSM-10, CNSSP 11, and CNSSP 15. Its direction applies to all NSS use of public
cryptographic algorithms (as opposed to algorithms NSA developed), including those on
all unclassified and classified NSS. Using any cryptographic algorithms the National
Manager did not approve is generally not allowed, and requires a waiver specific to the
algorithm, implementation, and use case. In accordance with CNSSP 11, software and
hardware providing cryptographic services require National Information Assurance
Partnership (NIAP) or NSA validation in addition to meeting the requirements of the
appropriate version of CNSA.

U/OO/194427-22 | PP-22-1338 | SEP 2022 Ver. 1.0

NSA | Commercial National Security Algorithm Suite 2.0

Introduction
This advisory includes the following sections:
 Algorithms for software- and firmware-signing. The National Institute of
Standards and Technology (NIST) standardized these algorithms some time ago,
but using different algorithms for this special use case is new in CNSA 2.0.
 Symmetric-key algorithms. There is only a modest change from CNSA 1.0 in this
section that allows a bit more flexibility.
 General-use quantum-resistant public-key algorithms. These are the main public-






key algorithms that most applications will require. As they have not completed
standardization, this section is forward-looking.
Timing. Discusses the timing of the transition to CNSA 2.0.
Enforcement. Summarizes requirements related to enforcing NSS algorithm
requirements.
Additional guidance: RFCs. Provides links to helpful Internet Engineering Task
Force Requests for Comment (IETF RFCs) used to implement CNSA 1.0.
Reference tables. Features two tables that list algorithms for CNSA 2.0 and for
CNSA 1.0.

Algorithms for software- and firmware-signing
The reasons for choosing separate algorithms for software- and firmware-signing are
three-fold:


NIST has standardized these algorithms already, while other post-quantum
signatures are not yet standardized,



This signature use-case is more urgent, and



This selection places algorithms with the most substantial history of cryptanalysis
in a use case where their potential performance issues have minimal impact. In
particular, this usage coincides well with the requirement for keeping track of
state—that is, how many times a given public key was used in signing software
or firmware when deploying these signatures.

The algorithms chosen for software- and firmware-signing are those specified in NIST
Special Publication 800-208. NSA recommends Leighton-Micali with SHA-256/192, but
all NIST SP 800-208 algorithms are approved for this use case. Note that to avoid

U/OO/194427-22 | PP-22-1338 | SEP 2022 Ver. 1.0

2

NSA | Commercial National Security Algorithm Suite 2.0

weakening the security of these signatures, you must meet all the requirements of SP
800-208, including the need to manage state and implement signing in hardware.
NSA encourages vendors to begin adopting NIST SP 800-208 signatures immediately.
For more information on requirement timelines, see the Timing section. The following
table lists CNSA 2.0 algorithms for software and firmware updates.
Table I: CNSA 2.0 algorithms for software and firmware updates

Algorithm
Leighton-Micali
Signature (LMS)

Function

Specification

All parameters approved

Asymmetric algorithm for
digitally signing firmware

NIST SP 800-208

and software

Xtended Merkle
Signature Scheme

Asymmetric algorithm for
digitally signing firmware

(XMSS)

and software

Parameters
for all classification
levels. SHA-256/192
recommended.

NIST SP 800-208

All parameters approved
for all classification
levels.

Symmetric-key algorithms
The following table shows the addition of SHA-512 to the list, the only change when
compared with CNSA 1.0.
Table II: CNSA 2.0 symmetric-key algorithms

Algorithm

Function

Advanced Encryption

Symmetric block cipher
for information

Standard (AES)

Secure Hash Algorithm
(SHA)

Specification
FIPS PUB 197

protection
Algorithm for
computing a
condensed
representation of
information

Parameters
Use 256-bit keys for all
classification levels.

Use SHA-384 or SHAFIPS PUB 180-4

512 for all classification
levels.

General-use quantum-resistant public-key algorithms
NIST recently announced its standardization selections for post-quantum cryptography.
Consequently, there are neither final standards nor Federal Information Processing
Standard (FIPS)-validated implementations available at this time. NSA is announcing

U/OO/194427-22 | PP-22-1338 | SEP 2022 Ver. 1.0

3

NSA | Commercial National Security Algorithm Suite 2.0

this selection of public-key algorithms to provide future NSS requirements so vendors
may begin building toward these requirements, and so acquisition officials and NSS
owners and operators will know what the requirements are.
Note that this will effectively deprecate the use of RSA, Diffie-Hellman (DH), and elliptic
curve cryptography (ECDH and ECDSA) when mandated. NSA urges NSS owners and
operators to pay special attention to these requirements. In the interim, CNSA 1.0
compliance continues to be required. The following section defines transition timelines
and the following table lists CNSA 2.0 algorithms:
Table III: CNSA 2.0 quantum-resistant public-key algorithms

Algorithm
CRYSTALS-Kyber

CRYSTALS-Dilithium

Function
Asymmetric algorithm
for key establishment
Asymmetric algorithm
for digital signatures

Specification
TBD

Parameters
Use Level V
parameters for all
classification levels.

TBD

Use Level V
parameters for all
classification levels.

Timing
The timing of the transition depends on the proliferation of standards-based
implementations. Because different technologies will adopt QR algorithms at different
paces, NSA is providing an overall transition end date and the process for determining
specific dates going forward.
NSA expects the transition to QR algorithms for NSS to be complete by 2035 in line with
NSM-10. NSA urges vendors and NSS owners and operators to make every effort to
meet this deadline. Where feasible, NSS owners and operators will be required to prefer
CNSA 2.0 algorithms when configuring systems during the transition period. When
appropriate, use of CNSA 2.0 algorithms will be mandatory in classes of commercial
products within NSS, while reserving the option to allow other algorithms in specialized
use cases.

U/OO/194427-22 | PP-22-1338 | SEP 2022 Ver. 1.0

4

NSA | Commercial National Security Algorithm Suite 2.0

The following is the general method for transitioning to CNSA 2.0 algorithm use:

1
2

NIAP will release protection profiles specifying that products support CNSA
2.0 algorithms in accordance with NIST and other standards from
standards development organizations and the development of standardscompliant cryptographic equipment.

All new equipment must meet the protection profile requirements; older
equipment must meet the requirement at its next update to remain NIAP
compliant.

3

Using CNSA 2.0 algorithms as the preferred configuration option will begin
as soon as validated and tested solutions are available.

4

NIAP Protection Profile requirements and NSM-10 technology refresh

5

At that point, legacy equipment and software not refreshed regularly will
require a waiver and a plan to bring it into compliance.

requirements will determine the removal of legacy algorithm support.

Timing for software signing and firmware signing
For software signing and firmware signing, NSA recommends:
1. Software and firmware signing begin transitioning immediately.
2. New software and firmware use CNSA 2.0 signing algorithms by 2025.
3. Transitioning deployed software and firmware not CNSA 1.0 compliant to CNSA
2.0-compliant algorithms by 2025.
4. Transitioning all deployed software and firmware to CNSA 2.0-compliant
signatures by 2030.

U/OO/194427-22 | PP-22-1338 | SEP 2022 Ver. 1.0

5

NSA | Commercial National Security Algorithm Suite 2.0

Other requirements for NSS
NSA anticipates the following timetable for implementing other CNSA 2.0 requirements
for NSS:








Software and firmware signing: begin transitioning immediately, support and
prefer CNSA 2.0 by 2025, and exclusively use CNSA 2.0 by 2030.
Web browsers/servers and cloud services: support and prefer CNSA 2.0 by
2025, and exclusively1 use CNSA 2.0 by 2033.
Traditional networking equipment (e.g., virtual private networks, routers):
support and prefer CNSA 2.0 by 2026, and exclusively use CNSA 2.0 by 2030.
Operating systems: support and prefer CNSA 2.0 by 2027, and exclusively use
CNSA 2.0 by 2033.
Niche equipment (e.g., constrained devices, large public-key infrastructure
systems): support and prefer CNSA 2.0 by 2030, and exclusively use CNSA 2.0
by 2033.
Custom applications and legacy equipment: update or replace by 2033.

Figure 1: Transition timeline
1 Even though hybrid solutions may be allowed or required due to protocol standards, product availability, or interoperability requirements, CNSA 2.0 algorithms

will become mandatory to select at the given date, and selecting CNSA 1.0 algorithms alone will no longer be approved.

U/OO/194427-22 | PP-22-1338 | SEP 2022 Ver. 1.0

6

NSA | Commercial National Security Algorithm Suite 2.0

Enforcement
NSS owners and operators must report on their progress in updating to CNSA 1.0 and
CNSA 2.0 as part of their responsibilities under NSM-8 and NSM-10. Approving Officials
(AOs) should measure compliance as part of the Risk Management Framework (RMF)
process when assessing Security Control 12 (SC-12). Furthermore, AOs will need to
verify compliance with CNSA 2.0 for software- and firmware-signing on their systems.
NSS should not be assessed against “FIPS-validated” in the RMF process; instead,
solutions must be NSA-approved. In applications where a commercial product is
accepted, NSA generally approves products that comply with CNSSP 11 (i.e., are NIAPvalidated against an approved protection profile), as long as they are configured
correctly in accordance with CNSSP 15 and other specific directions or guidance.

Additional guidance: RFCs
The following documents specify how to configure solutions to comply with CNSA
requirements. These include:









RFC 8603 "Commercial National Security Algorithm (CNSA) Suite Certificate and
Certificate Revocation List (CRL) Profile"
https://datatracker.ietf.org/doc/html/rfc8603
RFC 8755 "Using Commercial National Security Algorithm Suite Algorithms in
Secure/Multipurpose Internet Mail Extensions"
https://datatracker.ietf.org/doc/rfc8755/
RFC 8756 "Commercial National Security Algorithm (CNSA) Suite Profile of
Certificate Management over CMS" https://datatracker.ietf.org/doc/rfc8756/
RFC 9151 "Commercial National Security Algorithm (CNSA) Suite Profile for TLS
and DTLS 1.2 and 1.3" https://datatracker.ietf.org/doc/rfc9151/
RFC 9206 "Commercial National Security Algorithm (CNSA) Suite Cryptography
for Internet Protocol Security (IPsec)" https://datatracker.ietf.org/doc/rfc9206/
RFC 9212 "Commercial National Security Algorithm (CNSA) Suite Cryptography
for Secure Shell (SSH)" https://datatracker.ietf.org/doc/rfc9212/

These documents currently apply to CNSA 1.0. NSA will release updated guidance as
the standardization process progresses.

U/OO/194427-22 | PP-22-1338 | SEP 2022 Ver. 1.0

7

NSA | Commercial National Security Algorithm Suite 2.0

Disclaimer of endorsement
The information and opinions contained in this document are provided "as is" and without any warranties or
guarantees. Reference herein to any specific commercial product, process, or service by trade name, trademark,
manufacturer, or otherwise, does not constitute or imply its endorsement, recommendation, or favoring by the United
States Government, and this guidance shall not be used for advertising or product endorsement purposes.

Purpose
This document was developed to further NSA’s cybersecurity missions, including its responsibilities to identify and
disseminate threats and vulnerabilities to National Security Systems, Department of Defense, and Defense Industrial
Base information systems, and to develop and issue cybersecurity specifications and mitigations. This information
may be shared broadly to reach all appropriate stakeholders.

Contact
Cybersecurity Report Inquiries and Feedback: CybersecurityReports@nsa.gov
Defense Industrial Base Inquiries and Cybersecurity Services: DIB_Defense@cyber.nsa.gov
Media Inquiries / Press Desk: 443-634-0721, MediaRelations@nsa.gov

U/OO/194427-22 | PP-22-1338 | SEP 2022 Ver. 1.0

8

NSA | Commercial National Security Algorithm Suite 2.0

Appendix: Reference tables
The following two tables list the algorithms for CNSA 2.0 and for CNSA 1.0,
respectively. CNSA 1.0 is the current standard while CNSA 2.0 is the future one. NSA
recommends adopting the CNSA 2.0 software- and firmware-signing algorithms now.
Table IV: CNSA 2.0 algorithms

Algorithm
Advanced Encryption
Standard (AES)

CRYSTALS-Kyber

CRYSTALS-Dilithium

Secure Hash Algorithm
(SHA)

Function
Symmetric block cipher
for information

Specification
FIPS PUB 197

protection
Asymmetric algorithm
for key establishment
Asymmetric algorithm
for digital signatures

TBD

Use 256-bit keys for all
classification levels.
Use Level V
parameters for all
classification levels.

TBD

Use Level V
parameters for all
classification levels.

Algorithm for
computing a
condensed
representation of

Parameters

Use SHA-384 or SHAFIPS PUB 180-4

512 for all classification
levels.

information

Leighton-Micali
Signature (LMS)

All parameters
approved for all

Asymmetric algorithm
for digitally signing

NIST SP 800-208

classification levels.

firmware and software

SHA256/192
recommended.

Xtended Merkle

Asymmetric algorithm

All parameters

Signature Scheme
(XMSS)

for digitally signing
firmware and software

U/OO/194427-22 | PP-22-1338 | SEP 2022 Ver. 1.0

NIST SP 800-208

approved for all
classification levels.

9

NSA | Commercial National Security Algorithm Suite 2.0

Table V: CNSA 1.0 algorithms

Algorithm

Function

Advanced Encryption

Symmetric block cipher
for information

Standard (AES)
Elliptic Curve DiffieHellman (ECDH) Key
Exchange
Elliptic Curve Digital
Signature Algorithm
(ECDSA)

Secure Hash Algorithm
(SHA)

Asymmetric algorithm
for key establishment
Asymmetric algorithm
for digital signatures

NIST SP 800-56A

FIPS PUB 186-4

Algorithm for
computing a
condensed

FIPS PUB 180-4

representation of
information
Asymmetric algorithm

Key Exchange

for key establishment

RSA

FIPS PUB 197

protection

Diffie-Hellman (DH)

RSA

Specification

Asymmetric algorithm
for key establishment
Asymmetric algorithm
for digital signatures

U/OO/194427-22 | PP-22-1338 | SEP 2022 Ver. 1.0

Parameters
Use 256-bit keys for all
classification levels.
Use Curve P-384 for all
classification levels.
Use Curve P-384 for all
classification levels.

Use SHA-384 for all
classification levels.

Minimum 3072-bit
IETF RFC 3526

modulus for all
classification levels
Minimum 3072-bit

FIPS SP 800-56B

modulus for all
classification levels
Minimum 3072-bit

FIPS PUB 186-4

modulus for all
classification levels.

10