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 7-day horizon for undelivered ciphertext, and erasure on delivery — a re-fetch answers HTTP 410.
- 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 ships. 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 shipped crypto-core module.
Q-Ratchet · one message, start to finish
Follow one message through the ratchet.
-
A key is born
Four chains feed it: an X25519 exchange that turns every message, an ML-KEM-1024 epoch (FIPS 203, Category V) keyed against quantum decapsulation, an HKDF-SHA-512 symmetric chain, and a certified-QRNG entropy inject. The key exists for this message and no other.
-
Sealed
ChaCha20-Poly1305 seals the padded plaintext, and the entire ratchet header rides as associated data — tamper one byte of epoch, counter, or ciphertext and the tag refuses.
-
Sent
The relay sees a fixed-size blob and an opaque routing identifier. The sender's name travels inside the seal — sealed-sender envelopes (v2, rolling out) keep the outside of the packet anonymous.
-
Re-keyed
On delivery the relay nulls its copy in place, and both ratchets have already moved on. A full state compromise heals at the next ML-KEM-1024 epoch — one hundred messages, worst case.
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 mixes both peers' 64-byte certified-QRNG contributions, so neither side unilaterally controls the session secret.
- KEM
- ML-KEM-1024 (FIPS 203, Category V)
- Classical half
- X25519
- Combiner
- concatenation per SP 800-227 §6.2 · ML-KEM ss first · salt QERYX-HYBRID-v2-ML-KEM-1024-X25519 · info binds pk + ct
- Source
- crypto-core/src/hybrid.rs · session.rs
Four ratchets in parallel
Compromise of one key reads one message, never the conversation. Compromise of the whole state heals at the next post-quantum epoch.
- X25519 DH
- turns on every message
- ML-KEM-1024
- fresh encapsulation every 100-message epoch (cap 1,000)
- Symmetric chain
- HKDF-SHA-512, advanced per message
- QRNG inject
- every 5 messages of text · every 250 voice packets
- Source
- crypto-core/src/quadruple_ratchet.rs
The sealed frame
The serialized ratchet header — epoch, counters, X25519 public key, ML-KEM ciphertext, sync tag, QRNG 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
- ios/Qeryx/Services/CryptoService.swift
Delivery erasure
When your device acknowledges delivery, the relay nulls the row in place and marks the reason. A re-fetch answers HTTP 410, and the app renders the “Server-erased” pill. The caveats ship with the claim: a 10-minute soft-delete grace and a 7-day offline horizon for undelivered ciphertext, both published.
- On ack
- row nulled · erased_at set · reason fsor-delivery-erase
- Re-fetch
- HTTP 410 FSOR_ERASED
- Source
- backend/src/handlers.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 v2), though the relay still 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 erased at the relay
Acknowledged messages are nulled in place, and destroyed conversations retire their envelope epoch — the wrap key stops existing. What a later seizure finds is residue locked under a key that no longer exists.
Every destruction emits an ML-DSA-87-signed Merkle root you can check against the pinned operator key.
The Shield ladder. You arm each rung yourself.
Illustration of the shipped settings surface — every tier 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.
Your safety number is six groups of four, derived from the session transcript. Compare it in person or over another channel — a match is a proof, not a promise.
Behind it sits an append-only key log: a 2-of-3 multi-witness quorum (verify-only today — operator equivocation is detected, not prevented) plus three external Ed25519 auditor slots that ship dormant: all three hold placeholder keys, so no external cosignature is carried yet. Registry expansion is release-gated. 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 epoch | every 100 messages, cap 1,000 | 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. Not in this build — iOS gates the packet-tunnel provider on an Organization Team ID.
Keep the keys somewhere worthy
Secrets sealed under Argon2id and hybrid-wrapped ChaCha20-Poly1305, with a decoy vault beside the real one. Not in this build — it ships after v1, behind System ID.
Mail sealed to the recipient
The same primitives carry your email — burn-after-read when it matters. Not in this build — it ships after v1, behind System ID.
Worth switching?
| QERYX | Classical E2E | SMS-tier | |
|---|---|---|---|
| Real workloads | |||
| Full key compromise | Heals within 100 messages — the next ML-KEM-1024 epoch reseals; every-message classical ratchet on top | Classical-only recovery; quantum-readable later | No recovery — plaintext at the carrier |
| Server subpoenaed | Ciphertext + routing metadata under a published retention ladder; destroyed conversations cryptographically erased | 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 | Stream shield, scrim, and overlay block surface capture | Not included | Not included |
| Deletion trace | FSOR erasure with an ML-DSA-87-signed destruction root | Delete-flag rows and backups persist | Carrier logs persist |
Get it. Every tier carries the full crypto.
What is in this build?
The messenger, whole: text, media, voice, video, groups, disappearing messages, panic wipe, decoy PIN. Every one of them runs the same Q-Ratchet, the same hybrid handshake, the same seal. Channels ship after v1. Nothing in the app is for sale — v1 is an invited cohort with no tier gate anywhere in it.
What ships on every tier?
Everything is maximum for everyone. Higher tiers unlock new tools — they never upgrade the crypto you already have.
What does Armed unlock?
The ecosystem around the messenger: QLEAP VPN, QVault, QMail, QWallet, and HydraSIM. None of those four apps is in this build; the ladder that unlocks them opens after v1.
Armed is for everyone — the name means readiness, and when the ladder opens it funds the floor tier's independence from ads and data sales. See the tiers for the full ladder.
What does Shadow unlock?
The Underground: QSeal, Shadow ID, and Ghost Serpent — sealed work above the messenger floor. The compartment is not in this build; it opens after v1.
The messenger itself gains nothing it did not already have. Shadow adds rooms, never better locks.
The hard questions.
What can be handed over under subpoena?
Live, undelivered messages: ciphertext blobs plus routing metadata under the published retention ladder. Delivered messages: erased rows. Destroyed conversations: a retired envelope epoch — the wrap key no longer exists. 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. Share your public Profile ID to 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 no free tier?
Sustainability without surveillance. There are no ads, no data sales, and no telemetry product to fall back on, so when the ladder opens the Armed tier funds the Philanthropic floor and the subscription is the entire business model.
v1 charges nothing regardless — it is an invited cohort, and the app carries no purchase surface at all.
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). Production AEAD today is ChaCha20-Poly1305 (RFC 8439), a documented deviation; the AES-256-GCM NSS suite is implemented and reserved as suite 0x0002, staged for rollout. Pre-evaluation checklist: 0 non-conformant findings, 3 documented deviations (NIAP ETR, 2026-05).
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 today; 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 — not a completed EAL 4+ certification. Deviations are enumerated; formal evaluation in progress.
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 v2), though the relay still 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?
The rows are deleted, the caches purge, and the envelope key for that epoch is destroyed — residue in any backup is locked under a key that no longer exists. Every destruction emits an ML-DSA-87-signed Merkle root you can verify. Details on Disappearing & Sealed.
Can I verify any of this?
Yes. The crypto library beneath every platform is open — crypto-core — the protocol parameters are published, and the safety-number instrument above runs the comparison on your own device. Claims anchor to artifacts, not adjectives: read the security spec.