4.0 QMail
Mail sealed to the recipient. Burn-after-read when it matters.
Post-quantum encrypted email with a secure portal for outside recipients: token-linked, burn-after-read, and a key-health view of everyone you write to.
- FIPS 203 — ML-KEM-1024
- FIPS 204 — ML-DSA-87
- RFC 8439 — ChaCha20-Poly1305
- Prekeys MAIL_PREKEY_V1
- Hybrid X25519 + ML-KEM-1024
- AEAD ChaCha20-Poly1305
- Signatures ML-DSA-87
01 / THE PORTAL — LIVE
Seal a message, open it once, and watch it go.
The portal below seals a message in your browser, issues one token, and honors the burn: after you open and burn it, the key is discarded and the sealed bytes answer to no one.
A message sealed to one link. Open it once, and it is gone.
one-use token · qeryx.com/portal#tk_…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.
Sealing the demo message in your browser.
02 / THE ENVELOPE — LETTERED
Read the envelope, section by section.
The compose
Mail keys begin as hybrid prekeys: X25519 and ML-KEM-1024 agree a fresh secret for the thread, and the thread ratchets from there. It is the same crypto-core that seals the messenger — one audited path, no mail-shaped exception.
- Prekeys
- MAIL_PREKEY_V1 · X25519 + ML-KEM-1024 (FIPS 203)
- Thread keys
- Q-Ratchet, per thread
- AEAD
- ChaCha20-Poly1305 (RFC 8439)
- Identity
- ML-DSA-87 (FIPS 204) signed sender
The portal
Recipients without QERYX get a controlled door: a token-linked URL, gated by a password you share out-of-band. The message decrypts in their browser session and walks four states — locked, decrypting, decrypted, invalid.
The portal's floor is the password you share and the TLS session that carries it — we state that floor, never hide it. App-to-app mail rides post-quantum prekeys end-to-end; the portal trades that for reachability. Send app-to-app when it matters most.
ML-KEM-1024 · ChaCha20-Poly1305 · Zero-KnowledgeThe chip at the portal's foot, verbatim from the shipped surface.
The burn
The token is consumed at first open. A second visit finds an honest dead end: “This portal link has expired or was already consumed” — the shipped error, word for word. The 404 is not a failure page. It is the feature keeping its promise.
The sender
Every message carries the sender's signed identity, and the portal shows the signature algorithm on the envelope. Before you send, the key-health view surfaces each recipient's prekey freshness and verification state — you see the state of the lock before anything leaves your device.
Your SYSTEM ID signs you into Mail and Vault. It appears nowhere else in the ecosystem.
The attachments
Attachments chunk-encrypt on the same media pipeline as the messenger. The AAD binds file_id, chunk_index, and total_length — a shuffled, truncated, or spliced file refuses to open.
- Label
- MAIL_ATTACH_V1
- AAD binds
- file_id · chunk_index · total_length
The 404 is the feature. A burned message answers to no one.
Key health before you write
Every contact carries a visible key state: prekey freshness and verification, surfaced at the compose line. A stale or unverified key is something you see, never something you discover later.
This portal link has expired or was already consumed
Verbatim from the shipped portal. The dead end is the design.
The honest dead end
A consumed portal yields nothing — no preview, no metadata echo, no “contact support to restore.” The link dies because the message did. That is the whole promise, kept in one line.
03 / THE COUNTS — FOOTNOTED
Check every count against its receipt.
One read1
a burn-after-read portal message survives exactly one unlock
42
portal states: locked, decrypting, decrypted, invalid
03
content keys the mail server holds
| Parameter | Value | Source |
|---|---|---|
| Prekeys | MAIL_PREKEY_V1 · X25519 + ML-KEM-1024 | FIPS 203 |
| Thread keys | Q-Ratchet, per thread | crypto-core |
| AEAD | ChaCha20-Poly1305 | RFC 8439 |
| Sender identity | ML-DSA-87 signatures | FIPS 204 |
| Attachments | MAIL_ATTACH_V1 · chunked, AAD-bound | crypto-core |
04 / THE COUPLINGS — ONE CORE
Trace where the mail touches the rest of the stack.
What the mail shares, and with what
- QVAULT · ONE SYSTEM ID — The same SYSTEM ID signs you into Vault; the ecosystem login lives in Mail and Vault, and nowhere else.
- Q-RATCHET · ONE KEY DISCIPLINE — Mail threads ratchet on the same discipline as your messages: a fresh key, forward and onward.
- CRYPTO-CORE · ONE RUST CORE — MAIL_PREKEY_V1 and MAIL_ATTACH_V1 are crypto-core labels: the same audited library beneath every QERYX platform.
05 / THE VERDICT — CATEGORY COLUMNS
Set sealed mail against the two categories it replaces.
| QERYX | Classical encrypted mail | Plain email | |
|---|---|---|---|
| Real workloads | |||
| Provider breached | Sealed envelopes | Mailbox-at-rest keys often provider-held | Full plaintext |
| Quantum recording today | Post-quantum prekeys | classical exchange, readable later classical exchange, readable later | Not included |
| Outside recipient | Token + password portal, burn-after-read | Attachment passwords, or nothing | Not included |
| Server subpoenaed | Sealed envelopes + delivery metadata under the retention ladder; burned mail is gone | Stored mail produced | Full mailbox produced |
| Sender authenticity | Signed identity on the envelope | Domain-level signal only | Spoofable |
06 / ACCESS — WITH ARMED
Take the mail with the Armed tier.
What unlocks it?
QMail ships inside the Armed tier, everything unlimited. Nothing is purchasable in this build: the app carries no checkout surface and no price. No ads and no data sales anywhere in the model. Tiers add tools; they never upgrade the crypto you already have.
Do the people I write to need QERYX?
No. App-to-app mail is the strongest path, and the secure portal reaches everyone else: a token-linked page, a password you share out-of-band, and a burn when you set one.
07 / THE HARD QUESTIONS
Ask what the portal trades away.
How does someone without QERYX read my mail?
They open a token-linked portal over TLS and unlock it with the password you share out-of-band. The message decrypts in their browser session, then burns if you set it to.
What does the mail server store?
Sealed envelopes and routing data. Content keys live with you and your recipient — the server holds none.
What can be handed over under subpoena?
Sealed envelopes and delivery metadata under the retention ladder. Burned portal messages are gone.
Is the portal as strong as app-to-app mail?
No — and we say so. App-to-app rides post-quantum prekeys end-to-end; the portal trades that for reachability and protects the link with a token plus a password you control. Send app-to-app when it matters most.
Can I verify who sent a message?
Every message carries the sender's signed identity, and the portal shows the signature algorithm on the envelope.
Why not classical encrypted mail?
Classical mail encryption has no post-quantum prekeys, no burn-after-read, and leaks subject lines and metadata by default. QMail seals the thread and gives outside recipients a controlled door.