1.1 Voice & Video
Voice that stays clear when the network does not.
Calls keyed by the same hybrid handshake as your messages — ML-KEM-1024 + X25519, with caller and callee identities and the call ID bound into the media key — and codecs and forward error correction tuned to hold a voice through failing networks.
- FIPS 203
- FIPS 204
- KEM ML-KEM-1024
- Hybrid X25519
- Per-packet AEAD ChaCha20-Poly1305
- Call-init signature ML-DSA-87
01 / THE CADENCE MAP — MEASURED
Count the four cadences under one second of voice.
02 / THE CALL — LETTERED
Open the call and read it, section by section.
Call keying
A call opens with the same hybrid agreement as your messages — ML-KEM-1024 + X25519 — and a call-init blob signed under ML-DSA-87. The signature binds caller and callee Profile IDs, the ML-KEM ciphertext, a 16-byte call ID, and the timestamp: replay-bound by construction.
- Signature
- ML-DSA-87 · ctx QERYX-call-v1
- Binds
- caller + callee Profile IDs · ML-KEM ct · 16-B call ID · timestamp
- Source
- crypto-core/src/calls.rs
The voice ratchet
Four layers turn beneath the audio: a fresh ChaCha20-Poly1305 key for every 20 ms frame, a chain ratchet every 100 packets, a full ML-KEM-1024 re-key about once a minute, and certified-QRNG entropy injected every 250 packets. Keys ratchet forward whether or not packets survive.
- Frame key
- every 20 ms of audio
- Chain
- every 100 packets (~2 s)
- PQ re-key
- every 3,000 packets (~60 s)
- Source
- crypto-core/src/evs.rs · PROTOCOL_SPEC §10
The media path
Voice and video route relay-only. There is no public-IP candidate path between peers, so the person you call never learns your address — closed by construction, not by setting. The relay forwards opaque packets under keys it never holds.
- Routing
- relay-only · no peer-to-peer candidates
- Video
- same Q-Ratchet primitive · per-frame AEAD · 1080p
- Source
- VideoEncryptionPipeline.swift
Loss and recovery
Q-Cadence pairs each frame with a redundancy frame from the previous packet — a single lost packet recovers without added latency. Voice quality holds because the recovery is structural, and we leave it at that: cadences are the claim, adjectives are not.
- Redundancy
- previous-packet frame carried forward
- Voice-message padding
- EVM-Pad duration buckets — length hides from ciphertext size
The manifest
Every call ends with a receipt: an ML-DSA-87-signed summary of call ID, duration, codec rate, and the keying-transcript hash. What happened on the wire is signed, not remembered.
- Q-Manifest
- signed end-of-call summary
- Source
- crypto-core/src/q_manifest.rs
Bell, precisely
Bell-binding sits above the hybrid floor, never below it — the classical guarantee never weakens. On a call it is conditional, not automatic: the binder folds a Bell root only when both legs advertise the capability and both carry the same transcript epoch, which means both peers have completed the ceremony. Otherwise the call keys on the hybrid floor alone, and the code takes that branch by default. Where the fold does apply, the transcript is CHSH-verified and Tsirelson-window-validated, seeded by both peers and recheckable by any auditor.
A key lives for twenty milliseconds of audio. Then it is gone.
The call screen holds still so the crypto can turn
Calls run portrait, with the Q-Orbital chip carrying the live keying state — you watch the ratchet turn while you talk. Verified means the safety numbers matched; the chip says so or it says nothing.
03 / THE CADENCES — FOOTNOTED
Check every cadence against the file it came from.
20 ms1
of audio per ChaCha20-Poly1305 frame key
~60 s2
between full ML-KEM-1024 re-keys mid-call
03
public-IP candidate paths — calls route relay-only by construction
| Parameter | Value | Source |
|---|---|---|
| Frame key | every 20 ms of audio | evs.rs:54-91 |
| Chain ratchet | every 100 packets (~2 s) | evs.rs |
| PQ re-key | ML-KEM-1024, every 3,000 packets (~60 s) | evs.rs |
| QRNG injection | every 250 packets | evs.rs |
| Call-init signature | ML-DSA-87, ctx QERYX-call-v1 | calls.rs |
| Video | per-frame AEAD, 1080p | VideoEncryptionPipeline.swift |
| End-of-call receipt | ML-DSA-87-signed Q-Manifest | q_manifest.rs |
04 / THE VERDICT — CATEGORY COLUMNS
Set a QERYX call against the two categories it replaces.
| QERYX | Classical E2E | SMS-tier | |
|---|---|---|---|
| Real workloads | |||
| Key compromise mid-call | Per-packet keys + 60 s ML-KEM re-key | Per-call key, classical only | No call encryption to compromise |
| Server subpoenaed | Routing metadata only; media never stored | Signaling plus some metadata | Call records, optional intercept |
| Call recorded today, decrypted later | Hybrid ML-KEM-1024 handshake forecloses it | Classical media keys readable later | Cleartext at the carrier |
| IP disclosure to the peer | Relay-only — closed by construction | Peer-to-peer leaks it by default | N/A — carrier-routed |
| Member removed mid group call | Per-stream sender-key rotation | Typically none | N/A |
05 / THE HARD QUESTIONS
Ask what the relay can still hear.
Does the relay hear my call?
No. Media is sealed per packet under keys the relay never holds; it forwards opaque packets and nothing else.
Does the person I call learn my IP?
No. Calls route relay-only; there is no direct peer-to-peer candidate path to leak it.
What survives a bad network?
Redundant frames recover single-packet loss without added latency, and the keys ratchet forward regardless of loss — a dropped packet never stalls the crypto.
Are calls post-quantum too?
Yes. The call handshake is the same ML-KEM-1024 + X25519 hybrid as your messages; every per-packet key derives from it.
Can a recorded call be decrypted later?
Recording the ciphertext buys an adversary a break requirement of both X25519 and ML-KEM-1024 — and the per-packet keys are gone after use.
What about group calls?
Per-stream sender keys. A member ejected mid-call does not keep keys for subsequent frames — rotation is forced, not polite. More on Groups & Channels.