Solutions · 04
Evidence your evaluators can verify line by line.
An evidence package your evaluators can verify line by line.
Take the asymmetric core, stated once
The conformance claim ships in one fixed wording, everywhere it appears:
Canonical wording — verbatim
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.
| Primitive | Standard | Role |
|---|---|---|
| ML-KEM-1024 | FIPS 203 | Key encapsulation, Category V |
| ML-DSA-87 | FIPS 204 | Identity signatures |
| X25519 | RFC 7748 | Classical hybrid component |
| ChaCha20-Poly1305 | RFC 8439 | Default AEAD (documented deviation) |
| AES-256-GCM | suite 0x0002 | NSS suite, implemented and reserved |
| HKDF-SHA-512 | RFC 5869 | Key derivation |
The hybrid combiner concatenates the ML-KEM and X25519 shared secrets under HKDF-SHA-512, salted by the ciphertexts and bound to the public material — the NIST SP 800-227 §6.2 construction. Reading a recorded session requires breaking both components.
Read the evaluation posture without varnish
NIAP Common Criteria: READY WITH DEVIATIONS on our own pre-evaluation — not a completed EAL 4+ certification. The deviations are enumerated in the artifact bundle; no accredited-laboratory evaluation has begun, and the evidence bundle is being completed for one. FIPS 140-3: Algorithm-conformant, not module-validated. ML-KEM-1024, ML-DSA-87 and AES-256-GCM execute in a library whose validated configuration is not the one we link; ChaCha20-Poly1305, HKDF-SHA-512, X25519 and the hash functions execute in separate audited implementations. Every primitive passes a pinned known-answer test at every launch of the app and every start of the relay, and a failed test stops the process. No QERYX module holds a FIPS 140-3 certificate.
The evidence package — Security Target, extended-components definitions, side-channel test evidence, SBOM, and audit history — is provided through the evaluation channel and summarized in the Trust Center. We publish the caveats with the claims; an evidence package that hides its deviations is not evidence.
Scope the deployment on your own terms
Self-hosting is in development: the relay will run on your hardware, by your staff, inside your enclave — it holds ciphertext and opaque routing identifiers, so operating it will grant no one the power to read.
The security floor is the same for your personnel as for every civilian. A session is as secure as its weakest end — so the floor is maximal for both ends.
Ask for the field systems in the right room
Infrastructure-independent transports and field awareness surfaces — mesh radio, acoustic pairing, team coordination — are a separate line, in development, and stay out of the civilian messenger on purpose. They are briefed and scoped through the evaluation channel, not marketed on consumer pages.
05 / THE EVALUATOR’S QUESTIONS
Ask the four an evaluator opens with.
Where does QERYX stand on FIPS 140-3?
Algorithm-conformant, not module-validated. ML-KEM-1024, ML-DSA-87 and AES-256-GCM execute in a library whose validated configuration is not the one we link; ChaCha20-Poly1305, HKDF-SHA-512, X25519 and the hash functions execute in separate audited implementations. Every primitive passes a pinned known-answer test at every launch of the app and every start of the relay, and a failed test stops the process. No QERYX module holds a FIPS 140-3 certificate. Test vectors are pinned in the tree at crypto-core/src/fips_module.rs and run at every boot; the artifact bundle collects them with their provenance when it reissues.
Is this an EAL 4+ certification?
No. The posture is READY WITH DEVIATIONS from our own pre-evaluation — the deviations are enumerated, the evidence bundle is being completed for an accredited laboratory, and no evaluation has begun. We do not claim a certification we do not hold.
Why is the default AEAD ChaCha20-Poly1305?
It is the documented deviation in the canonical wording above: ChaCha20-Poly1305 (RFC 8439) performs consistently across heterogeneous devices without AES hardware. The AES-256-GCM NSS suite is implemented and reserved as suite 0x0002.
Can we operate the backend ourselves?
Yes, by design: the relay will deploy from a compose file onto your hardware; the kit is not public yet, so scope it through the evaluation channel. The carrier model means your operators will hold no content keys — the self-hosting docs show where the path stands.
Bring your evaluators.
The dossier answers in primitives, artifacts, and named deviations.