INVITE ONLY
OBSERVATORY

Research

protocol-spec

The QERYX Protocol: Overview and Design Goals

Version
v1.0
Category
protocol-spec
Published
Last updated
Authors
QERYX Research
Primitives ML-KEM-1024 ML-DSA-87 X25519 ChaCha20-Poly1305 HKDF-SHA-512
What changed v1.0
  1. v1.0 First publication — the reviewer-grade specification snapshot, submitted for state-actor-tier external review.
Contents
  1. §1 What QERYX is
  2. §2 Threat model in one paragraph
  3. §3 Seven design goals
  4. §4 Architecture
  5. §5 The chapter map
  6. §6 What this spec does not cover

This is the tier-1 summary of the QERYX cryptographic protocol specification (Entangled v1), the single normative description of every primitive, key, and wire format that ships in the iOS, Android, and backend artifacts. All load-bearing claims cite a path and line in the shipping source; where specification and code diverge, code is canonical and the divergence is listed in the Known Limitations chapter.

What QERYX is

QERYX is a public-global encrypted messaging system. Three artifacts ship from this repository:

  • Messenger — 1:1 and group text, voice messages, media, voice and video calls, on iOS and Android.
  • Backend — a Rust relay that holds blind ciphertext blobs, runs the WebSocket fan-out, the Key Transparency log, the QLEAP relay directory, and the FSOR at-rest envelope service.
  • crypto-core — one Rust library shared by client and server. Every primitive instantiation, key derivation, ratchet state, signature framing, and the FIPS 140-3 module boundary live here. No platform implements cryptography outside this library.

The threat model, in one paragraph

QERYX is designed against a network observer with full passive and active capability on every link, a server operator that may be coerced or compromised, and an adversary that may possess a cryptographically-relevant quantum computer. Endpoints are partially trusted: the Q-Ratchet defends against post-compromise attackers, and no cryptographic protocol defends against an adversary in continuous control of an unlocked device. The full adversary catalog is the Threat Model paper.

Seven design goals

#GoalMechanism
1 Post-quantum confidentiality and authenticity ML-KEM-1024 (FIPS 203) + ML-DSA-87 (FIPS 204), hybrid with X25519
2 Forward secrecy + post-compromise security Q-Ratchet: four parallel chains
3 Server-blind by construction ciphertext + per-conversation blinded participant hashes only
4 Cryptographic erasure FSOR envelope-key advance on destroy
5 Operator-distrusted key transparency append-only Merkle log, ML-DSA-87 Signed Tree Heads, STH gossip
6 Domain separation everywhere FIPS 204 §5.2 ctx per signature slot; labeled info per HKDF call
7 Constant-time primitive surface constant-time comparisons, implicit-rejection decapsulation, hedged signing

Architecture

CLIENTS (iOS / Android) messaging · KTS · calls BACKEND (Rust relay) blind blobs · WS · FSOR crypto-core — one library, both sides
FIG. 1 — identical crypto bytes on both ends: the clients link the library over FFI, the backend links the same crate. Identical known-answer tests gate both.

The chapter map

The specification is split for readability. Each chapter is published here as its own versioned paper:

  1. Cryptographic Primitives and Parameter Sets — protocol-spec, v1.0.
  2. Identity and Key Transparency: Serpent ID, Profile ID, and the KTS Log — protocol-spec, v1.0.
  3. The Hybrid Handshake: SP 800-227 Combiner and Entangled Session v1 — protocol-spec, v1.0.
  4. Q-Ratchet: Four Parallel Ratchets — protocol-spec, v1.0.
  5. Message AEAD, Frame Header v2, and the Padding Ladder — protocol-spec, v1.0.
  6. FSOR: Cryptographic Erasure of Server-Held Ciphertext — protocol-spec, v1.0.
  7. Group Messaging: Sender Keys with Post-Quantum Rotation — protocol-spec, v1.0.
  8. The QERYX Threat Model — security-analysis, v1.0.
  9. CNSA 2.0 and FIPS Conformance Posture — conformance, v1.2.
  10. Known Limitations and Open Work — security-analysis, v1.0.
  11. Entanglement-Anchored Key Agreement — white-paper, v0.1.

Chapters covering calls and media, the QLEAP VPN, and side-channel implementation detail exist in the repository but are not yet published here: those surfaces are under active build, and a chapter publishes only after a shipped-equals-spec re-verification. Their absence is the honest state, not an omission.

What this specification does not cover

A specification that claims every surface specifies none of them. These surfaces sit outside this document by design.

  • Wire-level transport binding — standard TLS 1.3 beneath the protocol layer.
  • App-level UI invariants.
  • Ancillary products (QVault, QMail, QWallet) that reuse this crypto stack but are specified in their own modules.
  • Compliance procurement collateral — see the CNSA 2.0 and FIPS posture paper.

Normative keywords (MUST, SHOULD, MAY) follow RFC 2119 and RFC 8174.