1.0 Messenger
A fresh key for every message you send.
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.
- FIPS 203
- FIPS 204
- CNSA 2.0 — asymmetric core conformant (R-1 scoping)
- KEM ML-KEM-1024
- Hybrid X25519
- AEAD ChaCha20-Poly1305
- Signatures ML-DSA-87
- KDF HKDF-SHA-512
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.
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.
-
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.
-
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.
-
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.
-
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 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.
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).
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 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
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
| Parameter | Value | Source |
|---|---|---|
| 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 |
It composes with the rest.
Route it through three hops
QLEAP will carry the messenger through three ML-KEM-1024-keyed hops, each peeling exactly one layer. In development — QLEAP arrives in a later update.
Keep the keys somewhere worthy
Passwords, notes and codes that stay on your iPhone, each sealed under its own key, with a decoy vault beside the real one.
Mail sealed to the recipient
The same primitives carry your email — burn-after-read when it matters. In development — it follows the messenger, behind System ID.
How it compares.
| 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.
Can QERYX read my messages?
No. The server is a dumb encrypted blob relay. It cannot read messages. Keys exist only on your devices.
Do the people I message need QERYX too?
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.
What if I lose my device?
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.
Why ChaCha20-Poly1305 and not AES-256-GCM?
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.
When do quantum computers matter?
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.
Can I use several devices?
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.
Is there a backdoor?
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.
What does sealed sender actually hide?
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.
What happens when I delete a conversation?
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.
Can I verify any of this?
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.