Evaluation · Government & Defense
Bring your cryptographer.
Canonical posture wording, file-and-line citations, and an intake that reaches an engineer — nothing on this page rounds up.
Read the posture in its canonical wording
Your reviewer gets one wording per program — the same one, everywhere it appears.
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.
READY WITH DEVIATIONS on our own pre-evaluation — not a completed EAL 4+ certification. The deviations are enumerated; no accredited-laboratory evaluation has begun, and the evidence bundle is being completed for one.
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.
One scoping note your reviewer will look for: CNSA 2.0 disallows QKD for national security systems, and QERYX agrees with the reasoning. The Q-Entangle-Bell lane is a KDF-bound co-possession witness layered above the X25519 + ML-KEM-1024 floor — the classical floor never weakens, and the subpoena bar never leans on the quantum layer.
Take the briefing kit
Nine documents, written for the person who signs the technical risk.
| Document | What it answers |
|---|---|
| Executive brief | What QERYX is, what it replaces, what is built in the pinned tree — one page. |
| CNSA 2.0 map | Primitive-by-primitive conformance with file-and-line citations. |
| FIPS 203 / 204 conformance | ML-KEM and ML-DSA construction conformance, test-vector and context-framing cites. |
| Threat model | Twelve named adversaries, mitigations, and the residual risk we kept on the record. |
| Attack surface | Every external endpoint, every persisted secret, every plaintext store — none on the backend. |
| Performance benchmarks | Crypto, message, voice, and video numbers, with method statements where measurement is pending. |
| SBOM summary | Top dependencies and license review. |
| Audit history | Review timeline, findings closed, findings still open — both counts printed. |
| Evaluation FAQ | 25 questions your cryptographer asks before signing. |
- Kit v1.0
- Issued 2026-05-01 against a pinned tree. Archived: it predates the evaluator dossier and carries one module-status wording its own audit later corrected.
- Kit v2.0
- Reissues pinned to the current tree with the corrected wording and the 2026-05 report included. Download links publish here when it ships — not before.
- Until then
- Request the kit through intake; it ships after export screening, with its pinned commit stated.
Hold us to these commitments
Commitments a contract can reference — each one is an architecture fact, not a policy mood.
No key escrow, in any jurisdiction
There is no key-escrow path that hands message plaintext to a third party, and no master reset. The one escrow-shaped surface in the tree is disabled by build flag in release builds and disclosed in the audit history — you can verify the flag in the pinned sources.
Self-hosting on your hardware
The full relay stack reproduces from the tree onto hardware you control; clients point at your relay through build-time configuration. The reference deployment recipe is vendor-neutral — nothing in it binds you to our infrastructure.
Disconnected operation
The transport layer fails over across six bearers and degrades to text-only under sustained denial — documented behavior. Offline and air-gapped deployment lanes are scoped under government solutions and specified during intake.
CNSA-scoped build
The asymmetric core is conformant under the canonical wording above; the AES-256-GCM NSS suite is implemented and reserved as suite 0x0002. A deployment-scoped build pins the suite policy your accreditor requires.
Zero third parties in this intake
Mail is the intake. There is no web form because a form means a form processor, and this page ships none: no tracker, no CRM pixel, no analytics. Your first message reaches an engineer.
Reproduce it on your own hardware
The kit ships a pinned source snapshot, and every claim in it cites file and line inside that snapshot. Reproduction is your reviewer running the tree, on your hardware, without trusting this page:
# 1 — the primitive suite proves itself: pinned known-answer tests
cd crypto-core && cargo test
# 2 — regenerate the SBOM and diff it against the shipped one
./scripts/sbom.sh
# 3 — sweep the dependency graph for advisories
cargo audit
# 4 — boot the relay; the power-up KAT battery refuses an error state
docker compose up backendAnything that fails to reproduce is a finding — report it through intake and it lands in the audit history with a number, like every other finding.
Open the channel
One message starts it. Include the six fields and the first reply can be substantive.
- Organization and country — export screening happens before any kit ships.
- Sponsoring program or agency — named or described at the level you can share.
- Deployment model — hosted relay, self-hosted, or disconnected/air-gapped lane.
- Evaluation requirements — Common Criteria, FIPS, CNSA 2.0, or your national scheme.
- Accreditation authority — who signs your authority to operate.
- Requested artifacts — kit, dossier under evaluation terms, or a technical session.
Send to support@qeryx.com. No autoresponder sits on that mailbox.
06The cryptographer's questions — asked before a signature
Ask what your cryptographer asks.
What happens when a cryptanalytically relevant quantum computer arrives?
Message, call and group keys are established through ML-KEM-1024: one-to-one sessions and calls by the hybrid X25519 + ML-KEM-1024 handshake, group keys by an ML-KEM-1024 wrap. Vault items never leave the iPhone, and a synced vault’s relay manifest is sealed under the X25519 + ML-KEM-1024 hybrid. Harvest-now, decrypt-later is answered before the machine exists, and identity signatures are ML-DSA-87 (FIPS 204).
Can the operator be compelled to disclose plaintext?
The relay stores ciphertext only; message keys never reach it. Under compulsion there is nothing current to hand over, and forward secrecy plus signed destruction roots close the retroactive window. The full coercion analysis is threat-model entries A6, A7, and A11 on /trust.
What is the FIPS status, exactly?
Exactly this: 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. The boot-time known-answer battery is evidence of readiness, and only an accredited lab turns readiness into a certificate — no QERYX module holds one.
Can we run it with no connection to you at all?
Yes, by design. A self-hosted deployment will run your relay, your database, your keys — QERYX holds nothing and cannot see your traffic. The reproduction playbook above is the same recipe your operators use.
What is the side-channel posture?
Constant-time equality on every secret comparison and a constant-time backend for the post-quantum suite — a structural posture, labeled structural. On-silicon leakage assessment is an accredited-lab step and is stated as pending on /trust.
Where are the open findings?
In the audit history, numbered, with both counts printed — findings closed and findings open. A kit that lists only closed findings is a brochure; this one is an audit trail.
Start the evaluation.
Six fields, one mailbox, an engineer on the other end.