08 Security · Transparency
Read the deviations before the passes.
An audit index that hides its deviations is marketing. Every artifact below ships with its honest state — including the ones that are not ready.
01Evaluation — ready with deviations, self-assessed 2026-06
Count the deviations. There are five.
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.
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.
The five deviations, enumerated
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.
Cited once, from audits/NIAP_2026_05_24/06_cnsa2_conformance.md as amended, and identical wherever the register is printed.
FIPS status, stated precisely
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 — module validation is a separate claim we do not yet make.
Standards drafts
Drafts authored (draft-qeryx-*-00/-01); submission packages prepared. This line will say “submitted” when receipts exist, and not before.
02Formal proofs — five primitives, negative controls included
Re-run the proofs. The model hashes are published.
Five core primitives carry Verifpal symbolic proofs — 5 of 5 PASS1. Five further Q-Entangle-Bell models exist as source; their verification outputs publish with the next revision. Model hashes are published so a reviewer re-runs exactly what we ran.
| Primitive | Verified claim | Result |
|---|---|---|
| Q-Ratchet | forward secrecy under later long-term key compromise + bidirectional authentication | PASS 4/4 |
| Q-KEM-Trinity | confidentiality under partial component break | PASS 3/3 + negative control fails as designed |
| Q-GroupCipher | post-eviction payload + root confidentiality + commit authentication (sender-key abstraction) | PASS 3/3 |
| Q-Anamorph | duress payload confidentiality under compelled cover-key surrender | PASS 2/2 |
| Q-Threshold | secrecy under t−1 share leakage | PASS 3/3 + negative control fails as designed |
The negative controls matter: upgrading the modeled attacker past the claimed bound makes the prover produce a concrete attack trace, demonstrating the passes are non-vacuous rather than vacuously true.
03Build chain — attested, and what is not
Check the build chain in the present tense.
The build-attestation manifest format is in the tree (ML-DSA-87, ctx QERYX-attest-v1) and signs build outputs; the endpoint that serves it answers when a release provisions one, and the update-authenticity trust-root registry is not yet claimed.
SBOM — honest state
The current software bill of materials is pinned to an earlier tree and is not yet signed. It is being re-generated against the source tree; until then it is listed here as stale rather than presented as current. Dependencies themselves are version-pinned in the repositories.
Key transparency — what the quorum can and cannot do
2-of-3 multi-witness quorum that starts dormant — all three ML-DSA-87 slots and all three external Ed25519 auditor slots hold placeholder keys, so no cosignature is carried and no witness check runs yet. Every root, until the witnesses enroll, is signed by one operator ML-DSA-87 key, which your device verifies against a SHA-384 anchor compiled into the app and cross-checks peer-to-peer through gossiped log roots. Enrolling a witness takes a new app release, by design.
04Warrant canary — reissue ceremony pending
Look for a live canary. There is none to read.
Canary — reissue ceremony pending
The canary reissue ceremony and its monthly cadence have not yet begun for this site. This block will state the signed date, the clause set, and the transparency-log reference when they exist — a canary’s value is its freshness, and we will not display a stale one as live. The full clause semantics are documented at /security/disclosure.
05The record — the questions we get asked hardest
The hard questions.
Why publish deviations instead of fixing them first?
Because an evaluator finds them anyway, and a vendor who found them first — and documented them — is showing the evaluator the review actually happened. Each deviation carries its remediation path in the ETR.
Where is the full evaluator package?
The evaluator surface is /trust: conformance evidence, the maximal-claim table, and the methodology every number on this site footnotes to.