CNSA 2.0 is the mandatory algorithm suite for U.S. National Security Systems. This paper maps every QERYX primitive to its CNSA 2.0 line item and FIPS standard with honest per-line markers — COMPLIANT, PARTIAL, DEVIATES — and the justification for each deviation. A conformance document that hides its deviations is marketing; this one enumerates them.
The claim, exactly
CNSA 2.0 — asymmetric core conformant (ML-KEM-1024 + ML-DSA-87 at Category V; SHA-512 at or above the hash floor). Production AEAD today is ChaCha20-Poly1305 (RFC 8439), a documented deviation; the AES-256-GCM NSS suite is implemented and reserved as suite 0x0002, staged for rollout. Pre-evaluation checklist: 0 non-conformant findings, 3 documented deviations (NIAP ETR, 2026-05).
That paragraph is the whole claim — scoped to the asymmetric suite, with the deviation named in the same breath. Everything below is the evidence behind each clause.
Primitive-to-line mapping
| CNSA 2.0 line | Status | QERYX instantiation |
|---|---|---|
| ML-KEM-1024 (FIPS 203), mandatory by 2030 | COMPLIANT | the only KEM in the build; 1568 B public key, 32 B shared secret |
| ML-DSA-87 (FIPS 204, Category 5), mandatory by 2027 | COMPLIANT | the only protocol-signing primitive; ECDSA/RSA absent from every signing path |
| Key agreement | DEVIATES | X25519 hybrid with ML-KEM-1024 per SP 800-227, in place of P-384 alone (§3) |
| AES-256 AEAD | DEVIATES | ChaCha20-Poly1305 primary; AES-256-GCM implemented as the CSfC outer layer where strict AES is required (§3) |
| SHA-384 hashing | DEVIATES | SHA-512 throughout (§3); SHA3/SHAKE inside ML-KEM/ML-DSA as FIPS 203/204 mandate |
| HKDF (RFC 5869) on an approved hash | COMPLIANT | HKDF-SHA-512 for every derivation |
| DRBG with SP 800-90B entropy | COMPLIANT | OS CSPRNG, XOR-mixed with independent quantum-entropy sources |
| Password derivation | PARTIAL | Argon2id (RFC 9106) at m=512 MiB, t=2, p=4 — the modern consensus choice; PBKDF2-HMAC-SHA-256 at 600,000 iterations where a strict PBKDF2 is required |
The deviations, justified
X25519 in hybrid, not P-384 alone. X25519 is constant-time by construction in every mature implementation, immune to the invalid-curve and small-subgroup classes that demand extra care with P-384, and publicly vetted across the modern secure-transport ecosystem. The hybrid combines both shared secrets through HKDF, so breaking X25519 does not break ML-KEM-1024 and vice versa — the classical component strengthens the lattice floor rather than replacing any CNSA line.
ChaCha20-Poly1305 primary AEAD. Equivalent confidentiality (256-bit key) and integrity (128-bit tag), constant-time without hardware AES support — which matters on older field hardware. The CSfC dual-layer mode reintroduces AES-256-GCM as an outer envelope exactly where CNSA-strict AES is required; call sites opt in with one function.
SHA-512 where SHA-384 is named. SHA-384 and SHA-512 share the same 1024-bit Merkle–Damgård chaining state and compression function; SHA-384 differs by initial value and output truncation. SHA-512 preserves the full collision strength of the 384-bit hash while delivering 512 bits to downstream KDF expansion. We do not claim SHA-512 is strictly stronger — the internal chaining strength is identical — only that the longer output is operationally preferable for KDF chains and Merkle commitments. This wording was corrected in v1.2 after a NIAP Security Target finding; the changelog above records it.
FIPS 140-3 module lifecycle
PowerUp → SelfTest → Operational → Error
The module gate runs known-answer tests for ChaCha20-Poly1305,
HKDF-SHA-512, SHA-256, SHA3-256, ML-KEM-1024 (encaps/decaps roundtrip),
ML-DSA-87 (sign/verify roundtrip), and X25519 before any cryptographic
operation is permitted. State transitions are atomic; a single self-test
failure moves the module permanently to Error and rejects all further
crypto. Production callers pass through
require_operational() — a small set of internal HKDF utility
paths bypass the redundant check today, and closing that gap uniformly is
a named v1.1 item in Known
Limitations.
The two-build model
Both builds run the same algorithms. The public build ships without the
FIPS boundary feature: algorithm-conformant, implemented via a library
lineage holding FIPS 140-3 certificate #4631, with QERYX's own module not
yet CMVP-certified — and a runtime status surface that reports exactly
that, fips_feature_enabled = false, rather than implying
otherwise. NSS-targeted builds compile the lineage in its validated
configuration and report true. Reviewers auditing a
downloaded binary confirm the configuration through the signed build
attestation, not through marketing copy.
The wire-stable suite identifier any procurement can reference:
CNSA2.0-HYBRID-X25519-ML-KEM-1024Out of scope
A conformance scope has an edge. Everything below sits outside ours, stated before a reviewer has to ask for it.
- Type-1 status. QERYX meets the CNSA 2.0 crypto suite; it does not meet the physical and personnel controls Type-1 equipment requires, and does not claim to.
- FIPS 140-3 above Level 1. Higher levels require hardware-validated modules — out of scope for a phone application.
- Classified-side deployment. QERYX is unclassified.
References
- NSA, Commercial National Security Algorithm Suite 2.0 (CNSSP-15, 2022; refreshed 2024) and the CNSA 2.0 FAQ Cybersecurity Information Sheet.
-
QERYX conformance sources —
docs/CNSA_2_0_POSTURE.mdanddocs/SPEC/11-cnsa-and-fips-mapping.md. - NIST FIPS 203, 204, 197, 180-4, 202, 140-3; SP 800-38D, SP 800-56C, SP 800-90B, SP 800-227.
- RFC 5869, RFC 7748, RFC 8439, RFC 9106.
- Cryptographic Primitives and Parameter Sets — the master table this mapping covers line by line.