QERYX COMING SOON
OBSERVATORY

1.0 Messenger

A fresh key for every message you send.

Q-RATCHET Coming soon

Text, photo, video, and voice under Q-Ratchet: hybrid ML-KEM-1024 + X25519 key agreement with ChaCha20-Poly1305 sealing. A seizure yields ciphertext it cannot open and routing metadata under a published retention ladder — never a word you wrote.

The retention ladder is published, rung by rung: a 10-minute soft-delete grace, a 30-day horizon for undelivered ciphertext, operator-tunable between 1 and 90 days, and deletion after the delivery receipt — once the row is purged, a re-fetch finds nothing. A group message, sealed to each member by default, and a message read with Stealth Mode on or read receipts off are retired without a receipt the relay can match, so their rows wait for the horizon.

Tap to decrypt.

This is a real ciphertext, sealed in your browser's build of the same primitive the app uses. Flip a byte and watch the AEAD refuse it.

rerun open() on a corrupted frame

Real ChaCha20-Poly1305 (RFC 8439), compiled from Rust to WebAssembly, running in your browser. Same primitive family as the QERYX protocol; demo build, not the crypto-core module itself.

Q-Ratchet · one message, start to finish

Follow one message through the ratchet.

  1. A key is born

    Four chains are designed in: an X25519 exchange, an ML-KEM-1024 lane (FIPS 203, Category V) rooted at establishment, an HKDF-SHA-512 symmetric chain that turns every message, and an entropy re-injection lane. In protocol revision 1 the symmetric chain and the post-quantum root carry the seal; the other chains activate in protocol revision 2. The key exists for this message and no other.

  2. Sealed

    ChaCha20-Poly1305 (RFC 8439) seals the plaintext under a key that exists for that message alone, with a fresh 96-bit nonce and the entire ratchet header as associated data — tamper one byte of epoch, counter, or ciphertext and the tag refuses; the nine-step transport ladder pads the sealed frame after.

  3. Sent

    The relay sees a sealed blob on a nine-step size ladder and the recipient's account identifier. The sender's name travels inside the seal — the stored row carries no author, though the relay authenticates the sender at send time.

  4. Re-keyed

    On delivery the relay retires its copy, and the symmetric chain has already moved on. Healing a full state compromise takes a fresh ML-KEM-1024 encapsulation at the next epoch; a session that has not negotiated the epoch chain recovers by re-establishing itself.

The seal, lettered.

The hybrid handshake

Every session opens with both halves — reading it later requires breaking both X25519 and ML-KEM-1024. The handshake salt commits to the responder's exact key bundle and both key-exchange halves; identities signed with ML-DSA-87 and verified before any session state moves; prekey bundles carry an ML-DSA-87 binding signature that is refused when it fails to verify.

KEM
ML-KEM-1024 (FIPS 203, Category V)
Classical half
X25519
Combiner
both shared secrets into HKDF-SHA-512 · salt = the recipient’s bundle fingerprint and SHA-256 over the ephemeral key and the ML-KEM ciphertext · label QERYX_SESSION_v4_ROOT
Source
the 1:1 root derives on device; the crypto-core library form is printed on /technology

Four ratchets in parallel

Compromise of one message key reads one message, never the conversation. Compromise of the whole state heals when the next post-quantum epoch opens.

X25519 DH
turns on every message from revision 2
ML-KEM-1024
root encapsulation at establishment; in-session epoch rekey arrives in revision 2
Symmetric chain
HKDF-SHA-512, advanced per message
Entropy re-injection
revision 2 — OS CSPRNG plus the conditioned server-relayed pool
Source
crypto-core/src/quadruple_ratchet.rs

The sealed frame

The serialized ratchet header — epoch, counters, X25519 public key, ML-KEM ciphertext, sync tag, entropy commitment — is the AEAD's associated data. Tamper any byte and Poly1305 fails closed. Frame Header v2 stamps the sender's bundle generation, so a forced re-registration is detectable on the wire.

Signatures
ML-DSA-87 · FIPS 204 §5.2 ctx framing 0x00||len(ctx)||ctx||M · hedged signing per Appendix D
Source
crypto-core/src/sign87.rs · quadruple_ratchet.rs

What the wire shows

Message length hides in a fixed ladder before encryption: nine buckets from 256 B to 64 KiB, larger payloads rounded to the next 64 KiB boundary. An observer reads bucket sizes, never prose lengths.

Padding ladder
9 buckets · 256 B → 64 KiB
Source
CryptoService.swift

Delivery erasure

When your device acknowledges delivery, the relay marks the row deleted and the sweep hard-deletes it within twenty-five minutes; once the row is purged, a re-fetch finds nothing. The caveats ship with the claim: a 10-minute soft-delete grace and a 30-day horizon for undelivered ciphertext, operator-tunable between 1 and 90 days, both published; and a message read with Stealth Mode on or read receipts off, or a sealed group message, is retired without a receipt the relay can match, so its row waits for that horizon too. A photo, video, file or group voice note is stored apart from its message, encrypted, for up to 45 days after upload, unless the sender deletes the message for everyone or a chat timer purges it sooner.

On ack
marked deleted at the acknowledgment · hard DELETE by the sweep within 25 minutes · signed receipt
A group message, or a read without a receipt
retired without a receipt the relay can match · deleted at the offline horizon
A photo, video or file
stored apart from its message · deleted at its own expiry, up to 45 days after upload, or sooner by its sender
Re-fetch of a purged row
no row returned
Source
handlers.rs · main.rs · SPEC/06 §8.8

Out of order, within limits

Skipped message keys cache until their message arrives — bounded, then zeroized on drop. The limits are part of the spec, not an afterthought.

Skip cache
2,000 keys per session · zeroized on drop
Source
SPEC/04 §6.9

The server stores ciphertext it cannot read. That is the whole design.

The carrier invariant
Sealed sender · envelope shut
9f2c 41ab 07de 55c1 8e02 b7f4 6a19 d3e8 Tap to decrypt
Delivered. The envelope never named you. 09:41 · delivered
Routing ID · opaque
Illustration of the interface — authored demo content. Sealed-sender envelope state.

The envelope stays shut in transit

The outer envelope is addressed to the recipient alone; who wrote it is readable only after decryption, on the receiving device. 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 ladder. We publish the ladder because the caveat is the claim's proof of honesty.

This one is already gone from the relay. 09:41 · delivered
Server-erased · FSOR
Re-fetch → HTTP 410 · FSOR_ERASED
Illustration of the interface — authored demo content. Delivery-erasure state.

Delivered means deleted at the relay

An acknowledged message is marked deleted and purged within twenty-five minutes, and destroying a conversation deletes the rows the relay can tie to it; a one-to-one message, sealed by default, names neither its sender nor its conversation, so the destroy does not reach it, and it leaves on its own clock, as any message does. A group message, sealed to each member by default, and a message read with Stealth Mode on or read receipts off keep their ciphertext until the offline horizon instead. A photo, video or file is not deleted with its message: it stays stored apart, encrypted, until its own expiry, up to 45 days after upload, even after its conversation is destroyed, unless its sender deletes it sooner. Nothing on the relay’s disk is overwritten, so old disk pages and backups can still hold those rows as they were: end-to-end ciphertext the relay never had a key to, beside the routing columns that say who wrote to whom, and when. Where the relay’s own at-rest envelope wrapped a row, destroying the conversation also retires that envelope’s epoch.

Every destruction emits an ML-DSA-87-signed Merkle root you will be able to check against the pinned operator key. It records that the relay deleted the row; it cannot prove that no copy survives elsewhere.

The Shield ladder. You arm each rung yourself.

Illustration of the settings surface — every level is opt-in. Scope: surface capture only; a camera pointed at the glass is out of scope, and we say so.

Verify your peer yourself.

Verification happens once, in person, through the Entangled pairing, and is automatic from then on.

Behind it sits an append-only key log: 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. Identity signatures are ML-DSA-87 (FIPS 204).

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

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

VERIFY A PEER

24 hex characters in six groups of four — paste is fine. 0/24

DEMO INPUTS

THE COMPARISON RUNS IN YOUR BROWSER — NOTHING LEAVES THIS PAGE

Demo scope: these numbers are derived with real SHA3-256 (WebAssembly) from an authored demo transcript, and this pane demonstrates the QERYX safety-number format and verify flow. It performs no ML-DSA-87 signature verification — the app verifies peers with ML-DSA-87 (FIPS 204).

Real ChaCha20-Poly1305 (RFC 8439), compiled from Rust to WebAssembly, running in your browser. Same primitive family as the QERYX protocol; demo build, not the crypto-core module itself.

Numbers carry footnotes or they do not ship.

≤1001

messages — the worst-case window before a full compromise heals at the next ML-KEM-1024 epoch

92

fixed padding buckets, 256 B to 64 KiB — message length hides in the ladder

4103

the HTTP status an erased message answers with — the relay can no longer produce it

Messenger parameters — code-true
ParameterValueSource
KEM ML-KEM-1024 (Category V) FIPS 203
Classical half X25519 RFC 7748
AEAD ChaCha20-Poly1305 RFC 8439
Signatures ML-DSA-87, ctx-framed FIPS 204 §5.2
KDF HKDF-SHA-512 RFC 5869
Hybrid combiner concatenation, ML-KEM ss first SP 800-227 §6.2
PQ root ML-KEM-1024 at establishment; in-session rekey in revision 2 quadruple_ratchet.rs
Skip cache 2,000 keys per session, zeroized on drop SPEC/04 §6.9
Padding 9 buckets, 256 B → 64 KiB CryptoService.swift

How it compares.

Real workloads — category columns only
QERYX Classical E2E SMS-class
Real workloads
Full key compromise ML-KEM-1024 root set at establishment resists later quantum readout; in-session PQ re-keying arrives in revision 2 Classical-only recovery; quantum-readable later No recovery — plaintext at the carrier
Server subpoenaed Ciphertext + routing metadata under a published retention ladder; of a destroyed conversation, the rows the relay can tie to it deleted from its database, while a sealed one-to-one message keeps its own clock and its photos and files their own expiry Stored ciphertext with richer metadata Full plaintext and metadata
Traffic recorded today, decrypted later Hybrid ML-KEM-1024 floor forecloses it Readable once a cryptanalytic quantum computer exists Readable today
Screenshot attempt Chat rows show black in screenshots on this phone; recordings meet a scrim and an overlay Not included Not included
Deletion trace Hard delete after delivery, with an ML-DSA-87-signed destruction root Delete-flag rows and backups persist Carrier logs persist

The hard questions.

What can be handed over under subpoena?

Undelivered messages: ciphertext blobs plus routing metadata under the published retention ladder. Delivered messages: gone from the relay database once the purge has run, about 25 minutes after the delivery receipt, leaving a destruction receipt with a hash of the message’s id and its times for thirty-seven days. A group message, sealed to each member by default, and a message read with Stealth Mode on or read receipts off are retired without a receipt the relay can match, so their ciphertext waits for the offline horizon. Photos, videos and files: each stays stored apart, encrypted, with an upload record that names its uploader, until its own expiry, up to 45 days after upload, even after its conversation is destroyed, unless its sender deletes it sooner. Destroyed conversations: the rows the relay can tie to the conversation are deleted, and where the relay’s own at-rest envelope wrapped them, that envelope’s epoch is retired; a one-to-one message, sealed by default, names neither its sender nor its conversation, so the destroy does not reach it, and one still waiting, or read with Stealth Mode on or read receipts off, stays to the offline horizon. A database backup taken before a purge still holds the rows as they were. Reading content requires breaking both X25519 and ML-KEM-1024.

No. The server is a dumb encrypted blob relay. It cannot read messages. Keys exist only on your devices.

Yes — the seal needs both ends. The hybrid handshake runs between two QERYX devices, and the keys exist nowhere else; there is no SMS bridge and no gateway into other networks. Once QERYX arrives, your public Profile ID is how you will bring someone in.

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.

Constant-time performance on every device, with or without AES hardware, and a smaller side-channel surface. The standards posture, stated whole:

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.

For recorded traffic, they already do: harvest-now-decrypt-later is a present-tense collection problem, and the CNSA 2.0 national-security gate lands 2027-01-01. The hybrid ML-KEM-1024 floor answers the deadline, not a mood.

One device per identity at first; linked devices are on the roadmap. The carrier model makes multi-device harder on purpose — recovery state cannot be centralized server-side.

There is no lawful-access endpoint because there is no plaintext or metadata store to endpoint. Formal posture: NIAP 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.

The outer envelope is addressed to the recipient alone; the sender's identity is readable only after decryption. Sender identifiers are stripped from the stored message row (sealed sender), though the relay authenticates the sender at send time; the relay routes by opaque identifiers. Undelivered messages queue with routing metadata under a published retention ladder.

Deleting a one-to-one chat, or a group for everyone as its admin, deletes the rows the relay can tie to the conversation, and the caches purge; a member who deletes a group leaves it, and the relay keeps the group’s rows for the members who remain. A one-to-one message, sealed by default, names neither its sender nor its conversation, so the delete does not reach it: it leaves on its own clock, within about 25 minutes of its delivery receipt, or at the 30-day horizon if it is still waiting or was read with Stealth Mode on or read receipts off. Each photo, video or file stays until its own expiry, up to 45 days after upload, unless its sender deletes it sooner. Nothing on the relay’s disk is overwritten, so a backup of it still holds those rows as they were: end-to-end ciphertext the relay never had a key to, beside the routing columns that say who wrote to whom. Where the relay’s own envelope wrapped a row, that residue was never readable to anyone without the operator’s master key, and destroying the conversation retires the envelope’s epoch; against someone who holds the master, that retirement is policy, not mathematics. Every destruction emits an ML-DSA-87-signed Merkle root you will be able to verify. Details on Disappearing & Sealed.

Yes. The crypto library beneath every platform, crypto-core, is source-published for review, and the protocol parameters are published; a peer is verified once, in person, through the Entangled pairing. Claims anchor to artifacts, not adjectives: read the security spec.

Security overview Read the technology