QERYX COMING SOON
OBSERVATORY

Research Messenger

conformance

CNSA 2.0 and FIPS Conformance Posture

Version
v1.2
Category
conformance
Published
Last updated
Authors
QERYX Research
Primitives ML-KEM-1024 ML-DSA-87 AES-256-GCM SHA-512 HKDF-SHA-512 Argon2id
What changed v1.2
  1. v1.2 Corrects the SHA-512-for-SHA-384 hash note per a NIAP Security Target finding: identical internal chaining strength stated plainly; the substitution claim scoped to output length only.
  2. v1.1 Adds the FIPS 140-3 module-gate lifecycle, self-test KAT enumeration, and the primitive-to-FIPS mapping table from the reviewer-grade specification.
  3. v1.0 First publication of the CNSA 2.0 posture with per-line conformance markers.
Contents
  1. §1 The claim, exactly
  2. §2 Primitive-to-line mapping
  3. §3 The deviations, justified
  4. §4 FIPS 140-3 module lifecycle
  5. §5 The two-build model
  6. §6 Out of scope
  7. §7 References

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). The AEAD is ChaCha20-Poly1305 (RFC 8439), a documented deviation; the AES-256-GCM NSS suite is implemented and reserved as suite 0x0002. Pre-evaluation checklist (internal self-assessment against the NIAP Common Criteria bar, latest pass 2026-06): 0 algorithm-layer non-conformances, 5 documented deviations; no accredited-laboratory evaluation has begun.

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 lineStatusQERYX instantiation
ML-KEM-1024 (FIPS 203), mandatory by 2030 COMPLIANT the only KEM compiled in by default; 1568 B public key, 32 B shared secret
ML-DSA-87 (FIPS 204, Category 5), mandatory by 2027 COMPLIANT the only protocol-signing primitive on every QERYX slot; RSA appears only as RFC 9474 blind tokens on the sealed-send lane, and Ed25519 only in the dormant auditor slots
Key agreement DEVIATES X25519 hybrid with ML-KEM-1024 per SP 800-227, in place of P-384 as the classical component — register entry 2 (§3)
AES-256 AEAD DEVIATES ChaCha20-Poly1305 primary — register entry 1; AES-256-GCM implemented and reserved as suite 0x0002 (§3)
SHA-384 hashing COMPLIANT, with a registered deviation SHA-512 at or above the floor on every key-schedule path; SHA-384 in the transparency log and the FSOR receipts; a small set of SHA-256 integrity paths are register entry 3 (§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; a conditioned server-relayed pool is XOR-mixed into group sender-key roots as defense in depth, never relied on alone
Password derivation PARTIAL Argon2id (RFC 9106) — the vault floor is m=128 MiB, t=3, p=4, calibrated upward on the device; the relay hashes the sign-in secret at m=64 MiB, t=3, p=4; the local backup runs m=256 MiB, t=4, p=2 — the modern consensus choice; PBKDF2-HMAC-SHA-256 at 600,000 iterations where a strict PBKDF2 is required

The CNSA-line justifications, and the register

The register the site cites is five entries long, cited once, from audits/NIAP_2026_05_24/06_cnsa2_conformance.md as amended, and identical wherever the register is printed:

  1. ChaCha20-Poly1305 is the default AEAD; AES-256-GCM is implemented and reserved as suite 0x0002.
  2. X25519 is the classical half of the hybrid key agreement; the classical component of a CNSA hybrid is otherwise ECDH P-384, and the hybrid is what every session runs.
  3. SHA-256 and HMAC-SHA-256 survive in a small set of integrity paths — the persisted ratchet-state tag, the Profile-ID derivation, per-item vault keys and the distress time-based code — below the SHA-384 floor; each moves to a new versioned label.
  4. SHA-1 survives in exactly one place: the HMAC that RFC 8489 TURN requires for its message-integrity attribute. It is never part of the message plane or any QERYX-designed construction — and the distress time-based code runs HMAC-SHA-256, not SHA-1.
  5. SLH-DSA is present as fail-closed scaffolding for a future suite and cannot be invoked.

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 — and the SHA-256 residue. 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 at or above the floor is not a deviation. What is one, and is register entry 3, is the small set of SHA-256 and HMAC-SHA-256 integrity paths — the persisted ratchet-state tag, the Profile-ID derivation, per-item vault keys and the distress time-based code — each of which moves to a new versioned label. This wording was corrected in v1.2 after an internal Security Target finding; the changelog above records it.

FIPS 140-3 module lifecycle

PowerUp → SelfTest → Operational → Error

The module gate runs eight known-answer tests before any cryptographic operation is permitted: ChaCha20-Poly1305 against the RFC 8439 §2.8.2 vector, AES-256-GCM against the AES-256 GCM-specification vector mirrored in NIST CAVP, HKDF-SHA-512 with its extract step anchored to RFC 4231 Test Case 1, SHA-256 and SHA3-256 against the NIST "abc" digests, X25519 against RFC 7748 §6.1, ML-KEM-1024 against a pinned decapsulation answer plus a live encapsulate-decapsulate pair, and ML-DSA-87 against a pinned verification answer with two negative controls — a tampered message and a single flipped signature byte, both of which must be rejected — plus a live sign-verify pair. A software integrity self-test over the linked image runs last, after the HMAC technique it uses has itself passed a known-answer test. The ML-KEM and ML-DSA answers were captured from this implementation and pinned; the rest are published standard vectors. 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, and closing that gap uniformly is an open item named in Known Limitations.

The two-build model

The release build links the library in its default configuration — algorithm-conformant, with QERYX's own module not CMVP-certified — and the runtime status surface reports exactly that: fips_feature_enabled = false. A validated-configuration build lane exists in the dependency graph and has not yet been produced; when it is, the same surface will report true — and even that build leaves X25519, ChaCha20-Poly1305 and the key-derivation functions outside the validated boundary until they are moved onto the same library. Note the scope even then: the certificate that lineage holds was issued before FIPS 203 and FIPS 204 were finalized, and the signature binding is reached through the library's unstable surface, so ML-KEM-1024 and ML-DSA-87 sit outside its approved-algorithm list either way. The honest FIPS claim for the post-quantum pair is construction conformance and known-answer tests run at every boot — not module validation. The build-attestation manifest format is in the tree (ML-DSA-87, ctx QERYX-attest-v1); the update-authenticity trust root is not yet claimed.

The wire-stable suite identifier any evaluation can reference: 

CNSA2.0-HYBRID-X25519-ML-KEM-1024

Out 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.
  • National-security-system deployment. Out of scope.

References

  1. NSA, Commercial National Security Algorithm Suite 2.0 (CNSSP-15, 2022; refreshed 2024) and the CNSA 2.0 FAQ Cybersecurity Information Sheet.
  2. QERYX conformance sources — docs/CNSA_2_0_POSTURE.md and docs/SPEC/11-cnsa-and-fips-mapping.md.
  3. NIST FIPS 203, 204, 197, 180-4, 202, 140-3; SP 800-38D, SP 800-56C, SP 800-90B, SP 800-227.
  4. RFC 5869, RFC 7748, RFC 8439, RFC 9106.
  5. Cryptographic Primitives and Parameter Sets — the master table this mapping covers line by line.