# CNSA 1.0 vs CNSA 2.0: What Actually Changed **Source**: https://quantumsequrity.com/blog/cnsa-1-0-vs-2-0 **Category**: Compliance & Regulation --- [← Back to Blog](../../blog.html) Compliance & Regulation # CNSA 1.0 vs CNSA 2.0: What Actually Changed 10 min read When the National Security Agency replaced the Commercial National Security Algorithm Suite 1.0 with version 2.0 in September 2022, most coverage flattened the change to a single sentence: "they added post quantum algorithms". That is true, but it misses the structural shift that matters for vendors and acquisition officers. CNSA 1.0 was a fine grained classical cryptography catalog with two signature schemes, a single hash family, and parameterized key sizes. CNSA 2.0 is a different shape. It picks one algorithm per role, drops every form of classical asymmetric crypto, and ties each algorithm to a milestone year between 2025 and 2035. This article puts the two side by side and explains what changes for engineering, procurement, and audit. Both versions remain on the public record at the NSA media library, so anyone selling into National Security Systems can verify the comparison directly. ## CNSA 1.0 in One Page CNSA 1.0 was published in 2015 (originally as part of NSA's broader cryptographic guidance, with formal Suite B retirement following) and remained the operative catalog until CNSA 2.0 superseded it. It listed the following allowed algorithms: - AES-256 for symmetric encryption - ECDSA over the NIST P-384 curve for digital signatures - ECDH over P-384 for key agreement - RSA at 3072 bit minimum for signatures and key transport - Diffie-Hellman with 3072 bit modulus minimum for key agreement - SHA-384 for hashing The structure had a comfortable property. If your product handled TLS 1.2 with strong cipher suites, integrated with a federal Public Key Infrastructure that issued P-384 certificates, and used AES-256-GCM for bulk encryption, it was probably CNSA 1.0 compliant out of the box. The catalog harmonized with mainstream FIPS 140-2 modules and with the cryptographic primitives shipped in OpenSSL, the Microsoft CryptoAPI, and Java Cryptography Architecture providers. ## CNSA 2.0 in One Page CNSA 2.0 trimmed the catalog hard. The 2022 advisory lists only the following: - AES-256 for symmetric encryption (unchanged) - ML-KEM-1024 for key encapsulation, replacing all classical key exchange - ML-DSA-87 for general purpose digital signatures, replacing ECDSA and RSA - LMS, XMSS (with SHA-256 at 192 bit security or higher), or SLH-DSA for software and firmware signing - SHA-384 or SHA-512 for hashing - SHA-256 only inside LMS or XMSS Notably absent: every flavor of RSA, every elliptic curve, every classical Diffie-Hellman variant. The advisory and the accompanying FAQ are explicit. If an algorithm is not in the list, it is not approved. ## Side by Side: What Stayed, What Left, What Joined | Role | CNSA 1.0 | CNSA 2.0 | |---|---|---| | Symmetric cipher | AES-256 | AES-256 | | Hash | SHA-384 | SHA-384 or SHA-512 | | Key agreement | ECDH P-384 or DH 3072 | ML-KEM-1024 | | Public key encryption / KEM | RSA 3072 transport | ML-KEM-1024 | | Digital signature (general) | ECDSA P-384 or RSA 3072 | ML-DSA-87 | | Digital signature (software / firmware) | (covered under general) | LMS or XMSS or SLH-DSA | AES-256 is the only public key or symmetric primitive that survived unchanged. SHA-384 is preserved, but SHA-512 was added explicitly to give implementers more flexibility, especially when chaining ML-DSA or SLH-DSA at category 5 internal hashing. Everything in the asymmetric column changed. RSA, ECDSA, ECDH, and finite field Diffie-Hellman are all out. ML-KEM-1024, ML-DSA-87, and stateful or stateless hash based signatures are in. ## Why the Asymmetric Column Got Flattened Shor's algorithm, published by Peter Shor in 1994, is the canonical reason. A sufficiently large fault tolerant quantum computer running Shor's algorithm breaks RSA, ECDSA, ECDH, and finite field Diffie-Hellman in polynomial time. CNSA 1.0 algorithms were designed against classical adversaries, and they retain their classical security. They lose their quantum security on the day a cryptographically relevant quantum computer comes online, which most published defense estimates place between 2030 and 2040. NSA decided that the lead time for migrating NSS supply chains was longer than the most pessimistic quantum forecast. Rather than wait for a clear and present quantum threat, the agency chose to begin the transition early. This is the same logic that drives [harvest now, decrypt later](harvest-now-decrypt-later.md): a record made today against an RSA encrypted channel can be decrypted on the day of the break, regardless of whether the channel is still in production. ## The "One Algorithm Per Role" Choice CNSA 1.0 offered choice. A vendor could ship ECDSA, RSA, or both. A relying party could pick its preferred curve. CNSA 2.0 deliberately removes that choice for the general purpose role. ML-KEM-1024 is the key encapsulation mechanism. ML-DSA-87 is the signature scheme. There is no parameter to negotiate, no curve to pick. The reasons are pragmatic. First, post quantum algorithms have larger keys and ciphertexts, and standardizing on one parameter set lets hardware vendors plan for a single memory and bandwidth budget. Second, interoperability across thousands of NSS endpoints is easier when there is no negotiation surface to mis-configure. Third, FIPS 140-3 validation is faster when the queue is for a single algorithm rather than a family. Software and firmware signing is the only role with multiple acceptable choices, because the operational tradeoffs differ. LMS and XMSS are stateful, which means key management has to track signature counters across reboots and replicas. SLH-DSA is stateless, so it is easier to deploy, but signatures are larger. ## Hash Family Expansion CNSA 1.0 named SHA-384 only. CNSA 2.0 names SHA-384 and SHA-512. The expansion is not arbitrary. ML-DSA at category 5 internally chains SHA-512 in some XOF roles, and SLH-DSA category 5 instantiations also use SHA-512. Including SHA-512 in the catalog means a vendor does not have to mark a sub primitive as out of scope. SHA-256 is still permitted, but only inside LMS or XMSS, because the Internet Engineering Task Force RFC 8554 (LMS) and RFC 8391 (XMSS) parameter sets are defined with SHA-256 at well known security levels. Lifting SHA-256 to general purpose use would re open arguments about 128 bit security floors that NSA has already closed for NSS. ## Hybrid Mode and Crypto Agility CNSA 1.0 had no hybrid concept because there was no second family of algorithms to combine with. CNSA 2.0 explicitly permits hybrid mode, where a CNSA 2.0 algorithm runs alongside a classical one and the shared secret derives from both. This is the architecture that QNSQY uses, with X25519 paired with ML-KEM, and Ed25519 paired with ML-DSA. The full reasoning is in our [hybrid encryption article](hybrid-encryption.md). The advisory does not require hybrid, only permits it. NSA's preference is that systems be capable of running pure CNSA 2.0 by the end of the transition period, but during the migration window, hybrid is the conservative choice. The FAQ also clarifies that hybrid can sit on either side of a TLS or IPsec connection without breaking compliance, as long as both sides agree. ## What This Means for FIPS 140 Modules CNSA 1.0 modules were validated against FIPS 140-2 with a small number of well known cipher suites. CNSA 2.0 modules need FIPS 140-3 validation that includes ML-KEM, ML-DSA, and SLH-DSA. The Cryptographic Module Validation Program began accepting these algorithms after NIST finalized FIPS 203, 204, and 205 in August 2024. We covered the validation pipeline in our [CMVP and FIPS 140-3 article](cmvp-fips-140-3.md). A practical consequence is that vendors with existing FIPS 140-2 modules cannot simply re label them. Adding a post quantum algorithm requires going through the validation queue again, with full Implementation Under Test entries, Operational Testing, and security policy updates. Most vendors will need to issue new module versions and migrate customers across the boundary. ## Software and Firmware Signing: The Earliest Deadline The change that hits soonest is software and firmware signing, with a 2025 support and prefer date and a 2030 full use date in the [CNSA 2.0 timeline](cnsa-2-0-timeline-detailed.md). Under CNSA 1.0, code signing was usually RSA 3072 or ECDSA P-384 with a SHA-384 hash. Under CNSA 2.0, it is ML-DSA-87, LMS, XMSS, or SLH-DSA. This change is structurally harder than confidentiality migration because signing keys often anchor roots of trust that span device generations. A bootloader signed with RSA 3072 today is verified on the device for years. If the verification key is hard coded in silicon, switching to ML-DSA requires a hardware refresh. ## Other Algorithm Changes A few smaller items are worth noting. Random number generation is still expected to follow NIST SP 800-90A and 90B, which CNSA 1.0 also referenced, but CNSA 2.0 implicitly raises the bar by requiring entropy sources adequate for ML-KEM-1024 key generation, which consumes more bytes per operation. Key derivation functions remain at HKDF and other NIST SP 800-108 family functions, with the underlying hash bumped to SHA-384 or SHA-512. Mode of operation choices for AES (CTR, GCM, GCM-SIV, KW) are unchanged, but the FAQ flags GCM-SIV as the preferred mode for IoT and similar contexts where nonce management is fragile. ## What CNSA 2.0 Does Not Change It is worth being clear about what stayed the same. The scope of NSS systems is unchanged. The relationship between NSA cryptographic guidance and NIST FIPS standards is unchanged. The CNSSI 1253 control catalog still inherits NIST SP 800-53 controls and applies CNSS Policy 15 algorithm choices on top. Acquisition language patterns largely carry over, though the algorithm names have to change. For procurement officers, the workflow is mostly the same. The cryptographic algorithms in the deliverables list change. The validation evidence required (FIPS 140-3 certificate, security policy, configuration documentation) stays in the same place. ## Operational Tradeoffs Between the Two Suites CNSA 1.0 had small keys and signatures. An ECDSA P-384 signature is 96 bytes. An RSA 3072 signature is 384 bytes. ML-DSA-87 signatures are 4595 bytes. The size jump is dramatic, and it affects bandwidth budgets, log storage, certificate distribution, and embedded device flash budgets. Designers used to designing around 384 byte signatures have to rethink protocols where signatures appear at high frequency. ML-KEM-1024 ciphertexts are 1568 bytes. ECDH P-384 outputs are 48 bytes. Again the size difference matters at scale. A TLS handshake with hybrid ML-KEM adds roughly 1.6 KB of network traffic compared to pure classical ECDH. For high frequency handshake flows (mobile clients reconnecting, IoT devices waking up, satellite links with limited bandwidth), the additional overhead is meaningful. CNSA 2.0 algorithms are also computationally heavier. ML-DSA-87 signing takes more CPU cycles than ECDSA P-384 signing. This is generally tolerable on modern processors but can be noticeable on constrained devices. Implementations targeting 8 bit or 16 bit microcontrollers often need cryptographic accelerators to meet performance targets. ## FAQ **Q: Did CNSA 2.0 deprecate RSA entirely or just shrink it?** A: It deprecated RSA entirely for NSS. There is no RSA size that remains compliant under CNSA 2.0, and the only acceptable persistent RSA usage is verifying signatures on archived material, with a hard endpoint at 2035. **Q: Can I still use ECDH and ECDSA inside NSS during the transition?** A: Yes during the transition window, but only as part of a hybrid construction with ML-KEM or ML-DSA. Pure classical asymmetric crypto is non compliant after the relevant deadline for each equipment category. **Q: Why is AES-256 the only symmetric algorithm?** A: AES-256 has 256 bit symmetric security, which gives roughly 128 bits of post quantum security under Grover's algorithm. NSA chose 256 bit symmetric throughout to maintain a margin against quantum brute force. **Q: Is SHA-3 in CNSA 2.0?** A: SHA-3 is permitted in some NIST contexts but is not named in CNSA 2.0. The hash list is SHA-384, SHA-512, and SHA-256 only inside LMS or XMSS. **Q: Are CNSA 2.0 algorithms compatible with Common Criteria evaluations?** A: Yes. NIAP has updated relevant Protection Profiles to include ML-KEM and ML-DSA. We discuss this in our [NIAP and PQC article](niap-pqc-requirements.md). ## Sources 1. NSA Cybersecurity Advisory, Commercial National Security Algorithm Suite 2.0 (September 2022). https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF 2. NSA, CNSA 2.0 FAQ. https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF 3. NSA, Commercial National Security Algorithm Suite (CNSA 1.0) (Wayback / archived NSA pages). https://media.defense.gov 4. NIST, FIPS 203, 204, 205 (August 2024). https://csrc.nist.gov/projects/post-quantum-cryptography 5. CNSS Policy 15. https://www.cnss.gov 6. IETF RFC 8554 (LMS) and RFC 8391 (XMSS). https://www.rfc-editor.org ## Related Articles - [CNSA 2.0 Detailed Timeline](cnsa-2-0-timeline-detailed.md) - [Why RSA 2048 Will Break](why-rsa-2048-will-break.md) - [Hybrid Encryption Explained](hybrid-encryption.md) - [NIST FIPS Guide](nist-fips-guide.md) - [PQC for Government and Defense](pqc-government-defense.md) --- ### Protect Your Data Before Q-Day Arrives QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats. [Try QNSQY](../../pricing.html)