1.2 Groups & Channels
Group names, descriptions, and every word sealed end-to-end.
Groups and channels with names, descriptions, and content end-to-end encrypted — the relay holds the group avatar, the admin and owner identifiers, and the roster it delivers to, for routing — plus owner-signed admin rights and channel-scoped identities.
- FIPS 203
- FIPS 204
- Key distribution ML-KEM-1024
- Handoff signature ML-DSA-87
- Sender-key ratchet HKDF-SHA-512
- AEAD ChaCha20-Poly1305
01 / THE ROOM — SIX STATES
Step through the room, state by state.
Each member holds a 32-byte sender key that ratchets forward via HKDF on every message — QERYX_SENDER_KEY_RATCHET_v1 opens the chain, QERYX_CHAIN_RATCHET advances it, QERYX_SENDER_MSG_KEY_v1 derives each message key — with a post-quantum rotation every 100 messages.
One key per voice, one seal per message. The room never shares a single secret everyone could leak.
Every membership change forces a rotation. The fresh sender key is encapsulated to each remaining member as one ML-KEM-1024 ciphertext — and never to the member who left.
Remove someone and the next key is born without them. A quantum adversary holding their old state gains nothing forward.
A new member receives sender keys at the join index only. Messages before the join were sealed under keys that are never re-distributed.
History is unrecoverable by design — the room does not owe its past to its future.
The owner role signs the rights matrix: which admin may invite, remove, or post, and the ban list beneath it. Rights arrive signed, not asserted.
An admin change you did not sign is an admin change that did not happen.
Inside a channel you will be a channel-scoped identity: CSID = HKDF-SHA-512(identity_secret, "QERYX-channel-scoped-id-v1" ‖ channel_id)[0..16], with a matching per-channel ML-DSA-87 signing key so a post proves channel authorship without handing subscribers a cross-channel handle. Your Profile ID stays in 1:1 conversations. Channels open after v1.
A different you per channel — after v1: two channels derive two unrelated values.
02 / THE GROUP SEAL — LETTERED
Read the group seal, section by section.
Sender keys, hardened
Every member speaks under their own 32-byte sender key. It ratchets forward per message via HKDF and rotates on a post-quantum epoch — the construction is hardened sender keys with forced rotation, stated as exactly that.
- Ratchet labels
- QERYX_SENDER_KEY_RATCHET_v1 · QERYX_CHAIN_RATCHET · QERYX_SENDER_MSG_KEY_v1
- PQ rotation
- every 100 messages
- Source
- SenderKeyService.swift · SPEC/07 §9.2
Distribution and rotation
A sender key travels to each member as its own ML-KEM-1024 encapsulation, signed under ML-DSA-87. Membership change forces rotation: the fresh key is never encapsulated to the removed member, so their view of the room ends at the moment they left — quantum adversary included.
- Per member
- one ML-KEM-1024 ct (~1.5 KiB)
- Signature
- ML-DSA-87 · ctx QERYX-group-senderkey-dist-v1
- Source
- SPEC/07 §9.4–9.5
Every handoff signed
Every sender-key handoff is signed under ML-DSA-87 over the conversation, sender, recipient, epoch and payload, and a receiver refuses an unsigned or mis-bound install; individual frames are authenticated by the sender-key chain itself, with per-frame authorship signatures implemented in crypto-core and staged for the client. A stolen sender-key handoff cannot be installed: the ML-DSA-87 distribution signature is verified against the key-transparency-pinned identity, fail-closed.
- Installing a handoff requires
- the sender's ML-DSA-87 identity signature over conversation, sender, recipient, epoch and payload
- Skip window
- a 512-key skip buffer per (channel, sender) chain — 2,048 per room, 8,192 per device, and a forward walk that stops at 4,096 steps
- Source
- SPEC/07 §9.7
Who you are in a channel
Channels never see your Profile ID. You appear as a channel-scoped identity derived one-way from your identity secret and the channel — two channels derive two different values, and neither walks back to the first.
- CSID
HKDF(identity_secret, channel_id)- Profile ID
- 1:1 conversations only
The honest cost
Rotation is real work and we publish the math: at one hundred members, a full rotation moves about 600 KiB of ML-KEM ciphertexts and signatures — amortized to roughly 6 KiB per message. Groups that rotate on every removal pay for the property they get.
- Full rotation @ 100 members
- ~600 KiB · amortized ~6 KiB/message
- Source
- SPEC/07 §9.12
What groups do not defend
A current member leaking plaintext, and out-of-band screenshots. No group construction defends member discipline — we say so because a page that will not say so cannot be trusted on the rest.
Remove a member and the next key is born without them.
Admin power arrives signed
Membership changes arrive as ML-DSA-87-signed commits, verified against the committer's key-transparency-pinned identity before the roster moves. A commit that does not verify does not widen the room.
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.
03 / THE GROUP MATH — FOOTNOTED
Check the group math against the spec that fixes it.
1 ct1
fresh ML-KEM-1024 ciphertext per member on every rotation
1002
messages per post-quantum rotation epoch
| Parameter | Value | Source |
|---|---|---|
| Sender key | 32 B per member, HKDF ratchet per message | SenderKeyService.swift |
| PQ rotation | every 100 messages | SPEC/07 §9.2 |
| Distribution | one ML-KEM-1024 ct per member (~1.5 KiB) | SPEC/07 §9.4 |
| Handoff signature | ML-DSA-87, ctx QERYX-group-senderkey-dist-v1 | SenderKeyService.swift |
| Skip window | 512 keys per (channel, sender) chain; 2,048 per room, 8,192 per device | SenderKeyService.swift |
| Group calls | per-stream sender keys, rotation on ejection | SPEC/07 §9.11 |
04 / THE VERDICT — CATEGORY COLUMNS
Set a QERYX room against the two categories it replaces.
| QERYX | Classical E2E | SMS-class | |
|---|---|---|---|
| Real workloads | |||
| Member removed | Forced key rotation — the future is sealed to them | Often deferred to the next epoch, or none | No encryption at all |
| Group metadata under subpoena | Encrypted names and avatars; opaque routing identifiers | Plaintext group names and member lists are common | Full membership at the carrier |
| Traffic recorded today, decrypted later | ML-KEM-1024 rotation forecloses it | Classical sender keys readable later | Readable now |
| Impersonation inside the group | ML-DSA-87-signed handoffs, verified against the pinned identity; per-frame signatures staged | MAC-only — any key holder can forge | Spoofable sender |
| History for new joiners | Never — past keys are not re-distributed | Configurable; often shared | Full history on device swap |
05 / THE HARD QUESTIONS
Ask what the relay learns about the room.
Can the server list who is in my group?
Yes. The relay holds, per group, the set of account identifiers it must deliver to, and the admin and owner identifiers beside it — that roster is how it authorizes every delivery. What it never holds is the group name, the description, or a word of the content.
What does a removed member still see?
Everything up to their removal; nothing after. The next sender key is never encapsulated to them.
Can a new member scroll back?
No. Past sender keys are never re-distributed.
Can someone forge a message in my name?
Installing a sender key in your name requires your ML-DSA-87 identity secret — every handoff is signed and verified against the key-transparency-pinned identity, fail-closed. Individual frames are authenticated by the sender-key chain; per-frame authorship signatures are implemented in crypto-core and staged for the client.
What can be handed over under subpoena?
Wrapped sender-key blobs, ciphertext in transit, and the roster and routing identifiers under the retention ladder. Reading group content requires breaking ML-KEM-1024, the wrap that carries every sender key; the 1:1 lane additionally requires X25519.
What don't groups defend against?
A current member leaking plaintext, and out-of-band screenshots. No group construction defends member discipline.