CNSA 2.0 Edition

Status, in plain words

The program says this itself. Its status line, word for word:

Approved-mode build (FIPS 140-3 preparation) with the CNSA 2.0 algorithm profile: data protection and local state use ML-KEM-1024, ML-DSA-87, AES-256-GCM and SHA-384/SHA-512 only; offline licence, no network use. NOT FIPS 140-3 validated; QNSQY holds no CMVP certificate; no NSA, NIAP or CSfC approval.

Algorithms, function by function

The CNSA 2.0 table is fixed when the program is built and can only narrow the approved set; no flag, setting or licence field switches it off. A refused algorithm or mode stops the command before anything is written.

What is refused

• ML-KEM-512 and -768; X25519 and HQC hybrids and HQC.
• ML-DSA-44 and -65; SLH-DSA, FN-DSA, LMS and Ed25519 hybrids; HashML-DSA (not in the build).
• XChaCha20-Poly1305; the SHA3/BLAKE3 file profile; SHA-256, SHA3-256 and BLAKE3 in the hash command.
• Password-only files, password plus recipient, key escrow; unsigned encryption; opening a file without the sender's key.
• Unprotected private keys and Argon2id-protected keys.
• Sign-in and every network command; the vault, steganography, time-lock, threshold, deniable, polyglot, keyfile, remote backup and other features of the Standard edition.

Allowed commands: encrypt, decrypt, key generation, sign, verify, verify-integrity, hash, hash-verify, shred, scan, migrate, audit, version, status, self-test, zeroize and help, plus licence and Crypto Officer commands.

Other algorithms in the build, stated openly

These never protect your data. An authorizing official decides whether any of them counts as cryptography for security.

• Licence enforcement uses SHA-256, and the optional TPM binding uses HMAC-SHA-256 inside the TPM. How the licence is enforced and hardened is described in a restricted document for approved organizations.
• The start-up self-tests also run SHA-256, SHA3-256, HMAC-SHA-256, HKDF-SHA-256, ML-KEM-512 and -768, ML-DSA-44 and -65 and Ed25519 verification as known-answer tests; no service uses them.
• Local state and the audit chain use SHA-512 and HMAC-SHA-512 truncated to 32 bytes; the verify-integrity value is a 24-byte checksum under a public key, not an authenticity check.
• SHA-3 runs inside ML-KEM and ML-DSA, as their standards define (NSA allows this within an approved algorithm).

Safeguards

• Start-up self-tests: on Linux the AWS-LC module's own checks, then 19 known-answer tests and a software integrity test (HMAC-SHA-512 over the program) before any service. Any failure stops every command: exit code 70, no output.
• Crypto Officer role: a secret of at least 16 characters, stored only as a PBKDF2-HMAC-SHA-512 hash and checked on every run. Role-based authentication is what FIPS 140-3 Security Level 2 requires; here it is a design goal, not a validated level.
• Audit trail: every entry signed with ML-DSA-87, chained with SHA-512 and encrypted with AES-256-GCM. It cannot be switched off, a command whose entry cannot be written does not run, and a trail that fails its check is never reset. Security events also go to syslog on Linux and the Event Log on Windows.
• No network: no billing client, no update check, no log forwarding. On Linux a kernel filter installed at the start of every command ends the process if it opens a network socket; the desktop, terminal and MCP interfaces keep local sockets only. On Windows the build has no network code path; run as an administrator, data commands also block their own outbound traffic with a firewall rule.
• Zeroize: one command overwrites and removes the edition's stored state. It keeps its own state folder, separate from the Standard edition.
• Offline install kit: the programs, SHA-512 checksums signed with ML-DSA-87, the release public key in a form OpenSSL reads, a software bill of materials and a cryptography bill of materials, and the documents.

The certified module inside, and what its certificate does not cover

On Linux the edition runs SHA-2, SHA3-256, HMAC, HKDF, PBKDF2, AES-GCM, AES key wrap, ML-KEM and random bit generation inside the AWS-LC FIPS 3.1.0 module. That module's CMVP certificates (#5314 static, #5298 dynamic; FIPS 140-3, overall level 1) cover it only when built by its Security Policy's procedure and run on its tested systems (Amazon Linux 2023 on AWS Graviton4 and Intel Xeon). QNSQY builds and runs it differently, so the certificates do not cover this edition, and we do not say that QNSQY "uses a FIPS-validated module". ML-DSA is not in those certificates; it runs in QNSQY's own code on every platform, with no certificate. On Windows every algorithm runs in QNSQY's own code.

What has been tested

• The allowed algorithms are checked against NIST test vectors, and ML-KEM-1024 and ML-DSA-87 against OpenSSL 3.5 in both directions.
• On Linux, the licensed flow ran end to end on a release program: licence import, key generation, signed encryption and verified decryption of a small and a 70 MiB file, tampered copies refused with no plaintext written.
• On Windows 11 (a virtual machine), the same licensed flow ran as a standard user and as an administrator.
• The full test gate of 2026-10-14 ran over all three editions; its one failure, in this edition's MCP server, was fixed and re-tested. A 30-minute fuzz run of the file-signature parser found nothing.
• Not yet: the TPM licence binding has run only against a software stand-in, and the security-key binding only against a software token; no run on physical Windows hardware; no lab testing.

Sources

• NSA, Announcing the Commercial National Security Algorithm Suite 2.0 (September 2022).
• NSA, The Commercial National Security Algorithm Suite 2.0 and Quantum Computing FAQ (December 2024, version 2.1).
• NIST FIPS 203, FIPS 204, FIPS 197, FIPS 180-4, SP 800-90A Rev. 1, SP 800-132.
• NIST CMVP certificates #5314 and #5298 (AWS-LC 3).

More on the shared approved-mode design: Approved Mode edition. All three editions side by side: Editions. Availability and pricing: contact us; there is no release date yet.