Security — QERYX

CNSA 2.0 — scoped conformance

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.

01Threat model — six adversaries

Name your adversary. Read what stands against it.

Tap an adversary. Each answer names the module and the primitive that stands against it — and states what that module does not do.

State signals intelligence

Every session runs a hybrid key exchange: X25519 and ML-KEM-1024 combined through HKDF-SHA-512, so recording traffic today does not buy decryption by a future quantum computer. Q-Ratchet rotates keys per message; a captured key opens nothing before or after it.

Endpoint compromise

Forward secrecy bounds the blast radius: keys already ratcheted away cannot be recovered from a seized device. On the iPhone, a vault draws its key at random and seals it behind the owner's PIN and the platform secure enclave wherever it accepts the key, and, where a face is enrolled, binds it to the owner's face once the vault's recovery words are verified; at the vault's pad no PIN is checked or counted until Face ID confirms that face, wherever a face is enrolled and Face ID is on for QERYX, while QSeal's sign-in checks its own password first; the key of the PIN's envelope is derived with Argon2id — the vault calibrates itself on the device and never derives below m=128 MiB, t=3, p=4. A compromised endpoint still reads what its user can read — no protocol prevents that, and we do not claim one does.

Legal compulsion

The operator holds ciphertext and opaque routing identifiers — the full inventory is the ledger below. There is no key-escrow and no master reset, so there is no key to compel. Breaking a session requires breaking both X25519 and ML-KEM-1024.

Traffic analysis

The sender is stripped from the stored row and from the relay's logs; every message payload, and every typing and receipt frame, snaps to one of nine fixed sizes — 256 B to 64 KiB — at the WebSocket transport before it leaves the device; that ladder sits outside the ratchet's authenticated frame, so the relay and the stored row still see exact ciphertext lengths, and moving it inside the seal is protocol version 5. QLEAP's three-hop routing will raise the cost of linking endpoints when it lands; it is in development. Timing correlation by a global passive observer remains an open problem for every messenger, including this one.

Supply chain

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. ML-KEM and ML-DSA dispatch to an audited library whose validated configuration is not the one we link — QERYX’s own module is not CMVP-certified.

Physical seizure of the server

The exhibit below is the complete answer: sealed ciphertext, the identifiers the relay routes on, a queue with a stated retention period, and each file’s encrypted blob with the upload row that names its uploader. The plaintext rows are listed too — honesty about the residue is part of the design.

02The ledger — the carrier schema, field by field

Read the whole inventory the relay holds.

This is the row the relay actually writes for one queued sealed message, column by column, stamped with what each one yields to anyone who takes the machine.

Mixcōātl carrier ledger — one queued sealed message, in the INSERT's order

id The row identifier. Opaque
sender_id NULL on the sealed lane. The stored row does not name the author; the send that produced it was authenticated. Opaque
recipient_id The recipient’s internal account UUID, in the clear. This is the delivery address. Plaintext
encrypted_content The ML-KEM-1024 ciphertext and the sealed body, in one column — your message, sealed with ChaCha20-Poly1305 under keys that exist only on the two devices. Ciphertext
nonce 12 random bytes. Opaque
message_type, idempotency_key, created_at, pending_delivery, conversation_id Routing and de-duplication fields. Queue timestamp visible while the message waits. Plaintext
sequence_number, pair_sequence_number, conv_seq, conv_commit_seq Ordering counters. Opaque counters
envelope_kind sealed_sender_v1 — the marker that says this row has no author. Plaintext
group metadata Group names and descriptions and all content are end-to-end encrypted; the group avatar, the admin and owner identifiers, and the roster of accounts each conversation delivers to are held by the relay for routing. Ciphertext

Sender identifiers are stripped from the stored message row (sealed sender), though the relay authenticates the sender at send time. Undelivered messages queue with routing metadata under a published retention period — 30 days¹, with a shorter tiered ladder on the roadmap. Beyond this row the relay also keeps what it needs to route and to stop abuse: the conversation roster, a per-direction counter for each pair with a last-contact stamp, the one-day de-duplication ledger, parked receipts, the push-wake ledger, and — for any file you send — the upload row, which does name the uploader. Each one is listed with its lifetime in the retention ledger on /legal/privacy.

03Seizure — the disk image at T+0

Seize the relay. Open the disk image.

Exhibit — relay disk image, T+0

Delivered messages: gone once the sweep has run. The row is written before delivery, marked deleted at the recipient’s receipt, and hard-deleted within about 25 minutes. A group message, sealed to each member by default, and a message read with Stealth Mode on or read receipts off wait for the 30-day horizon.

Undelivered messages: sealed ciphertext plus the ledger rows above, held at most 30 days¹ before the purge job — which runs every fifteen minutes — deletes them.

Attachments: one ChaCha20-Poly1305 box over the padded file, sliced into 256 KB upload chunks on a metered link — the store never holds a content key, and the upload row names the uploader for as long as it lives: up to 45 days after upload, delivered or not, unless the sender deletes the message for everyone or a chat timer purges it sooner.

Keys: none. There is no key-escrow and no master reset. Breaking a session requires breaking both X25519 and ML-KEM-1024.

04Verify — SHA3-256 in your browser

Derive a safety number with your own hands.

In the app, a peer is verified once, in person, through the Entangled pairing, and the two devices compare the check for you. The instrument below derives a demo number in the open — real SHA3-256, in your browser, from an authored demo transcript. Rotate the demo session and watch the number change.

KTS · SAFETY NUMBERSHA3-256 WASM · LOADING

One number on two screens.

Your device and your peer’s each derive it from the session. If they match, your keys agree end to end — an interceptor cannot show you the same number.

YOUR DEVICE

0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF-0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF-0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF-0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF-0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF-0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF

Your safety number: BF4B-945F-A4B5-7A1E-D4D9-7C20

In the app: Q-Ratchet root key + both peers’ ML-DSA-87 public keys → HKDF-SHA512 → 16 bytes; the short form renders 12 of them as six groups of four hex characters.^{KTS-QUORUM SPEC}

In the app, key transparency rides a 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.

05Go deeper — nine surfaces

Take the next surface. Nine of them are open.

06Safe harbor — research, authorized in writing

Test us in good faith. This clause covers you.

Security research on QERYX conducted in good faith is authorized. If you make a good-faith effort to follow the disclosure policy — test only against your own accounts, avoid degrading service for others, do not access or retain another person’s data, and report promptly to support@qeryx.com with SECURITY in the subject — QERYX, the operating entity named in the Terms, will not initiate legal action against you for that research and will not refer it for prosecution. Where a third party raises a claim, we will state on record that your research was authorized. This clause is published policy pending final counsel review; the disclosure mechanics live at /security/disclosure.

07The record — the questions we get asked hardest

The hard questions.

Can QERYX read my messages?

No. The server is a dumb encrypted blob relay. Message keys are born and die on the two devices; the operator holds the ledger above and nothing else. The zero-knowledge page walks the whole path.

What happens if you are subpoenaed?

We can produce only what the ledger holds: sealed ciphertext, the identifiers the relay routes on, queue timestamps for messages not yet delivered or retired without a matching receipt, and each photo, video or file still within its lifetime, encrypted, with the upload row that names its uploader. Breaking a session requires breaking both X25519 and ML-KEM-1024.

Can you recover my account if I lose everything?

We cannot recover your messages or your account if you lose your device and your Secret Phrase. There is no key-escrow and no master reset.

Is any of this independently checked?

Five core primitives carry machine-checked Verifpal proofs — 5 of 5 PASS with non-vacuous negative controls¹ — and the conformance review is our own: an internal pre-evaluation against the NIAP Common Criteria bar, with its five deviations enumerated under transparency. Independent, accredited evaluation has not begun, and this page will say when it has. Artifacts live under transparency.

Next: Post-Quantum — keys built to outlast the recording