07 Security · Whitepaper
Check the protocol, chapter by chapter.
Fourteen chapters, from primitive table to known limitations. The specification is the claim — everything on this site cites into it.
01The atlas — fourteen chapters, one protocol
Take the atlas. Fourteen chapters, one protocol.
-
§1 Primitives Every algorithm, parameter set, and byte-locked wire value — the master table.
-
§2 Identity & KTS SERPENT ID, Profile ID, and the key-transparency quorum that watches the operator.
-
§3 Handshake & Session The hybrid X25519 + ML-KEM-1024 exchange and how a session is born.
-
§4 Q-Ratchet Per-message key rotation — forward secrecy and post-compromise recovery.
-
§5 AEAD & AAD ChaCha20-Poly1305 framing and what the associated data binds.
-
§6 FSOR Server Erasure Forward-secure operator erasure: how delivered rows die.
-
§7 Group Messaging Q-GroupCipher: group keys without the server learning the group.
-
§8 Calls & Media EVS-PQ binder call binding and QSEAL-Stream chunked media.
-
§9 QLEAP VPN Three-hop onion routing over an encrypted tunnel transport.
-
§10 Threat Model The adversaries, stated formally, with what each one gets.
-
§11 CNSA & FIPS Mapping Claim-by-claim conformance mapping, deviations enumerated.
-
§12 Side-Channel & Implementation Constant-time discipline, zeroization, timing surfaces.
-
§13 Known Limitations What QERYX does not defend against — in the spec, on purpose.
-
§14 Reviewer FAQ The questions evaluators ask, answered with citations.
Rendered, citable editions publish at /research with per-paper versioning and changelogs. Chapter §13 — Known Limitations — is part of the specification by design: a protocol document that lists no limits has not been reviewed hard enough.
02Reading paths — three, by what you came for
Pick your reading path.
I want the security argument
Read §10 (threat model), then §3 (handshake) and §4 (Q-Ratchet). Those three chapters carry the core claim: breaking a session requires breaking both X25519 and ML-KEM-1024, and keys already ratcheted away stay gone.
I am evaluating for procurement
Start at §11 (CNSA & FIPS mapping) and §13 (known limitations), then the artifact index at /security/transparency and the evaluator surface at /trust.
I want to implement against it
§1 is byte-locked: every wire-stable value is marked, and changing one is a documented compatibility break. Pair it with §5 for the framing rules and the label registry in crypto-core for the domain-separation contract.
Signed PDF — not yet issued
A signed PDF edition ships once the release-signing key ceremony completes. Until that signature exists, no download is offered here — an unsigned PDF dressed as a signed one is not an artifact.
03The record — the questions we get asked hardest
The hard questions.
Why publish the full protocol at all?
Because the security must live in the keys, never in the secrecy of the design. A protocol that cannot survive publication cannot survive a determined adversary either.
Has the specification been reviewed externally?
The NIAP pre-evaluation ETR (2026-05) reviewed the conformance surface — 0 non-conformant findings, 3 documented deviations — and five core primitives carry machine-checked Verifpal proofs1. Formal evaluation is in progress; we state it as in progress.