Architecture · Protocol specification

The Qlavis Citadel — the published specification of the cryptography in Qlavis · Messenger.

Every primitive with its standard and parameters, and the protocol compositions built on them. All primitives are NIST- or IETF-standardized; the compositions are Qlavis’s own, and they are specified on this page. Algorithm and parameter facts are verified against the production code.

01 The stack

Standard primitives.
Our composition.

“Post-quantum” is a spectrum: no end-to-end encryption at all → classical E2EE → post-quantum at session establishment only → post-quantum at establishment and in ongoing rekeying. Qlavis sits at that top level, at the maximum NIST parameter — and extends post-quantum protection to two surfaces the spectrum does not measure: authentication (the identity trust root and every protocol signature) and the real-time call plane. The result is the complete NSA CNSA 2.0 suite — ML-KEM-1024, AES-256-GCM, ML-DSA-87, SHA-2 — on every surface that touches user content, years ahead of the federal mandate (Executive Order 14412: post-quantum key establishment by 2030, signatures by 2031). Every algorithm is a published NIST or IETF standard — no proprietary cipher, hash, or signature anywhere — and every session secret is hybrid by construction: breaking it requires breaking a classical primitive and a post-quantum one.

Post-quantum key encapsulation ML-KEM-1024 FIPS 203 · Category 5 · every key exchange in the product

Post-quantum signatures ML-DSA-87 FIPS 204 · Category 5 · identity trust root & all protocol bindings

Authenticated encryption AES-256-GCM FIPS 197 + SP 800-38D · 96-bit nonce, 128-bit tag · every AEAD surface

Classical key agreement X25519 RFC 7748 · the classical half of the hybrid

Classical signatures Ed25519 RFC 8032 · cross-signs the PQ trust root · Stellar (chain-mandated)

XRP Ledger signatures secp256k1 RFC 6979 deterministic ECDSA · chain-mandated

Key derivation & hashing HKDF · HMAC · SHA-2 RFC 5869 / RFC 2104 / FIPS 180-4 · HMAC-SHA512 margin on calls & wallet

Recovery derivation BIP39 → SLIP-0010 12 words, 128-bit entropy · PBKDF2-HMAC-SHA512, 2048 rounds

Local database at rest SQLCipher 4.14.0 Page-level AES-256 · ratchet table doubly encrypted

Device binding Secure Enclave P-256 Private key never leaves the hardware

Post-quantum primitives run on Apple CryptoKit’s constant-time implementations. No custom cryptographic primitives — the composition is ours; the parts are not.

Post-quantum parameter level NIST L5 ML-KEM-1024 and ML-DSA-87 — the highest standardized category

Call key rotation 5 min Mid-call rekey with no renegotiation and no interruption

Message padding 256 B Uniform blocks — short messages indistinguishable by length

Server decryption paths 0 For user content — verifiable against the production schema under NDA

02 Identity

One 12-word phrase.
A post-quantum trust root.

There is no phone number, email, or third-party account. The entire identity derives deterministically from a 12-word BIP39 phrase (128-bit entropy), decoded via PBKDF2-HMAC-SHA512 (2048 rounds) into a 64-byte seed.

i

Two identities, one phrase.

The classical anchor — Ed25519, derived by SLIP-0010 at hardened path m/44'/637'/0'/0'/0' (the coin type is purely a domain separator, disjoint from the wallet paths) — and the post-quantum trust root — ML-DSA-87, generated from a secondary seed produced by HKDF-SHA256 over the same 64-byte seed with a versioned domain-separation string. Adding the post-quantum root changed nothing the user must back up.

ii

The migration cost users nothing.

The Ed25519 identity cross-signs the ML-DSA-87 public key. A peer holding a classical pin verifies that attestation and migrates its pin to the post-quantum root in-band — no re-verification ceremony, no safety-number change, no trust in the server, which holds only public keys and cannot forge the attestation.

iii

Pinning is partitioned by key stability.

The per-install X25519 and ML-KEM-1024 keys are random, not phrase-derived — a deliberate posture choice. Trust-on-first-use pins only the stable phrase-derived signature identity, so a reinstall raises no false alarm while a different phrase on the same handle locks the conversation. Peers also track a monotonic epoch on the published key bundle: an epoch moving backwards — the hallmark of a replayed or substituted bundle — raises a security state even when the identity matches.

iv

The device is bound in hardware.

A P-256 keypair generated inside the Secure Enclave — its private key never enters software memory — is registered as a fingerprint hash. A recovery on a different device changes the fingerprint and triggers a visible re-bind alert to the account’s other devices.

v

Recovery is phrase-blind.

The client re-derives the Ed25519 key from the entered phrase and signs a server-issued challenge; the server verifies against the public key on file. The phrase never leaves the device, and the server retains no phrase-derived material. The PIN fallback is stored only as a salted PBKDF2 hash; ten consecutive failures wipe all local key material — the phrase still recovers the identity on any device.

03 Handshake

PQXDH, instantiated with ML-KEM-1024 throughout.

Sessions are established with PQXDH — the published Signal handshake — in a hybrid instantiation. A published prekey bundle carries the peer’s identity keys, a signed prekey whose signature is made with ML-DSA-87 and verified under the pinned post-quantum identity, one-time prekeys, and ML-KEM-1024 prekeys. The initiator computes:

SK = HKDF-SHA256( DH1 ‖ DH2 ‖ DH3 ‖ DH4 ‖ SS1 ‖ SS2 )

     4 × X25519 Diffie–Hellman legs
   + 2 × ML-KEM-1024 encapsulations
   → 32-byte hybrid root key

Compromise of the session key requires breaking both X25519 and ML-KEM-1024. The ML-DSA-87 signature on the signed prekey also authenticates the negotiated post-quantum suite, so a relay cannot silently downgrade the KEM.

Inbound identity binding is fail-closed. Every session-initiation message carries the initiator’s ML-DSA-87 identity public key, its Ed25519 cross-attestation, and a binding signature over the initiator’s per-install X25519 key. The responder verifies the binding only under the pinned identity — never under a wire-supplied key. A binding that fails is treated as an attack: the session is not installed, the message is not attributed to the contact, a security warning is raised, and outbound sending is blocked pending re-verification. A malicious or compelled server cannot inject a forged handshake “from” a pinned contact — it cannot sign under keys that never leave the contact’s device.

04 Ratchet

QTR-1024 — the Qlavis Triskelion Ratchet.

Ongoing conversation keys come from the Double Ratchet construction extended with an independent post-quantum axis, at the maximum NIST parameter level.

04.1 · Three axes DH × chains × ML-KEM-1024

Rekeyed every 10 messages or 24 hours.

An X25519 Diffie–Hellman ratchet, symmetric chain ratchets (chain keys advanced by HMAC-SHA256 with domain-separating constants), and an independent ML-KEM-1024 ratchet that re-keys the post-quantum root every 10 messages or 24 hours, whichever comes first.

04.2 · Hybrid keys MK = KDF( DH_mk ‖ PQ_mk )

Every message key needs both axes broken.

Each message key derives from both the classical and the post-quantum axis, so forward secrecy and post-compromise security hold against a classical adversary today and a quantum adversary later. Signal and Apple chose 768-parameter KEMs in their ratchets for bandwidth; QTR-1024 carries ML-KEM-1024 (Category 5), trading roughly 3 KB per rotation for the highest standardized level.

04.3 · Loss tolerance re-inclusion · dedup · bounded confirm

Dropped and out-of-order messages don’t break the session.

A KEM encapsulation, unlike a DH value, is not idempotent — in prior post-quantum ratchets, losing the one message that carries new epoch material breaks the session. QTR-1024 re-includes the identical pending KEM ciphertext in every outgoing header until the peer confirms; the receiver keeps a bounded SHA-256 history of processed ciphertexts and decapsulates each distinct ciphertext exactly once, skipping duplicates without advancing state; confirmation is advertised across a bounded number of subsequent messages.

04.4 · AEAD & padding AES-256-GCM · 256-byte blocks

Sealed, authenticated, and length-hidden.

Message bodies are sealed with AES-256-GCM (fresh random 96-bit nonce, 128-bit tag) with the header bound as associated data, and padded to uniform 256-byte blocks so short messages are not distinguishable by length on the wire. Session state is snapshotted before any mutation during decrypt; a failed authentication restores the snapshot, so a tampered ciphertext cannot corrupt the session.

05 Calls

Post-quantum on every frame.
Enforced by the infrastructure.

WebRTC’s standard SRTP keying is classical, so Qlavis intentionally disables it and applies its own frame-encryption layer. Enforcement is not a client preference.

05.1 · Admission control fail-closed at the relay

A classical-only call is rejected before the phone rings.

In the enforcing production mode, the signaling relay validates every call offer before alerting the callee and rejects it unless it carries the post-quantum protocol version, the required post-quantum suite capability, well-formed ML-KEM-1024 ciphertext material, and an affirmative post-quantum-media flag. The answer passes symmetric checks. The callee’s device independently auto-declines an offer without KEM material before ringing, as defense-in-depth.

05.2 · Key agreement two-shot ML-KEM-1024 · call-scoped

Caller and callee derive identical keys from mirrored encapsulations.

The caller encapsulates against the callee’s ML-KEM-1024 public key and sends the ciphertext in the offer; the callee decapsulates, encapsulates against the caller’s key, and answers. Both sides derive identically — keys scoped to the single call by the salt, signaling and media keys split by domain; the relay sees only opaque ciphertexts:

master   = HKDF-SHA256( salt = callId, IKM = ss1 ‖ ss2 )
sigKey   = PRF( master, "call:sig" )     — signaling metadata
mediaKey = PRF( master, "call:media" )   — frame encryption

05.3 · Frame encryption AES-256-GCM · 5-min atomic rekey

Keys rotate mid-call with no glitch and no renegotiation.

Every audio and video frame is sealed with AES-256-GCM under the media key. A timer advances a bounded key index every five minutes; the frame key for index i derives deterministically from the media key and i, and the index rides in frame metadata — receivers roll forward without interrupting the stream.

05.4 · Identity binding Sig( callId ‖ ct ) · fail-closed

A key-swapping server kills the call.

Each party signs its call identifier and KEM ciphertext with its ML-DSA-87 identity key; the signature travels with the signer’s post-quantum public key and its Ed25519 cross-attestation inside an opaque signaling field the relay forwards verbatim. The receiver verifies the attestation under the pinned trust root, verifies the binding under the proven key, and pins the post-quantum identity on first sight from the call itself. A tampered ciphertext, missing attestation, classical-suite downgrade from a capable peer, or pin mismatch terminates the call — no safety-string comparison is required; the call inherits the already-pinned messaging identity.

05.5 · No degraded mode plus Hidden IP relay routing

If a call can’t be sealed post-quantum, it doesn’t connect.

There is no insecure-call state and no dismissible warning: any post-quantum failure on the call path means the call never establishes or is torn down. An optional per-call Hidden IP policy restricts the connection to relay-only (TURN) candidates, concealing the device’s address from the peer, with a logged best-effort degrade if no relay candidate is gathered in a bounded window.

06 Media & avatars

KEM-DEM per file.
Per-viewer grants for avatars.

06.1 · Media files fresh key per file · purge on delivery

The server stores an opaque blob it cannot read — then deletes it.

Each file is encrypted on the device under a fresh random 32-byte key with AES-256-GCM and uploaded as an opaque blob; the file key — never the file — is wrapped to each recipient via ML-KEM-1024 inside the end-to-end-encrypted message that references it. The server deletes the blob once the recipient’s device confirms durable receipt (successful decrypt and write to the device’s encrypted store), with a short grace window and an independent 14-day ceiling for never-fetched blobs; the delivery record deliberately carries no recipient identity. Forwarding re-encrypts under a fresh key and uploads a new blob — on the server, a forward is unlinkable to its original.

06.2 · Avatars one blob · N per-viewer wraps

One encrypted photo, one independent cryptographic grant per viewer.

A profile photo is encrypted once under a fresh symmetric key; for each permitted viewer the owner’s device encapsulates to the viewer’s ML-KEM-1024 key and seals the avatar key under the result with AES-256-GCM, tagging each wrap with its AEAD suite — not a single shared profile key. Rotating the avatar deletes the superseded blob and every old wrap. Viewers without a wrap enqueue a request the owner’s device fulfills on its next online tick, and the owner’s device reconciles per-viewer coverage at every launch — no viewer is permanently skipped. The server relays and indexes wraps it can never open.

07 Envelope & device

Notifications carry routing, never content.
The device is the durable home of history.

07.1 · Sealed sender defense-in-depth

Sender identity rides inside the encrypted body.

The sender’s identity is embedded inside the encrypted message body, hardening it against any path that strips or rewrites the transport envelope. Stated honestly: the relay still sees sender-to-recipient routing while a message row exists — what is never exposed at any layer is content.

07.2 · Push pipeline zero content · encrypted tokens

The push payload is routing metadata only.

The payload carries conversation and message identifiers and the sender’s handle for rendering; the encrypted body is fetched and decrypted by a notification extension on the device. A device-local setting hides the sender on the lock screen entirely. Push tokens are stored AES-256-GCM-encrypted at rest under a server-internal key and decrypted transiently, in memory, only at push-emission time.

07.3 · Local storage SQLCipher · Secure Enclave · iCloud-excluded

Everything at rest on the device is encrypted.

The entire local database is page-level encrypted with SQLCipher; the ratchet-session table carries an additional per-row AEAD layer. The wallet database is separate and independently keyed. Media history, thread overflow, and render caches are encrypted with AES-256-GCM under Keychain-held keys; all stores carry iOS file protection and are excluded from iCloud backup. App access is gated by Face ID / Touch ID with a PIN fallback; wallet signing re-prompts per transaction.

08 Wallet

Self-custodial, from the same twelve words.

The same BIP39 seed derives a self-custodial wallet: a Stellar Ed25519 key via SLIP-0010 at m/44'/148'/0' and an XRP Ledger secp256k1 key via BIP-44 at m/44'/144'/0'/0'/0' (RFC 6979 deterministic ECDSA). Keys live only on the device; the server stores no wallet balances, keys, addresses, or transaction history. An in-chat payment rides inside the conversation, sealed by the same ratchet as a text — the relay sees a ciphertext block, not an amount.

On-chain transaction signatures are what each chain mandates (classical today) — and we say so rather than overclaim. Both ledgers have published post-quantum roadmaps — Stellar toward 2027, the XRP Ledger toward 2028 — and the identity layer above them is already post-quantum.

09 The server

A blind relay — verifiable, not promised.

The server is a transport intermediary that cannot decrypt user content and holds as little as the protocol allows. We don’t call it zero-knowledge — that term means something else in cryptography. We call it what it is, and we write down what it does see.

09.1 · Key custody public keys only

No decryption key for user content exists server-side.

User private keys exist only on user devices, in the Keychain and Secure Enclave. The server holds public keys — Ed25519, ML-DSA-87, X25519, ML-KEM-1024, prekeys — the material any peer needs to start a session. Its only internal symmetric key encrypts push tokens. Client–server transport runs over TLS with certificate pinning — a second envelope around content that is already end-to-end encrypted.

09.2 · Data minimization purge on delivery · 14-day ceiling

Content is purged on confirmed delivery, on every plane.

Delivered message content is erased at delivery (a content-less stub remains for delivery status); delivered media blobs are deleted on durable receipt; a call’s signaling row is deleted the instant the call ends — long-term call history exists only on the user’s device. A 14-day ceiling backstops everything undelivered. Contact lists never reach the server. Account deletion notifies each former peer individually and retains no global registry of deleted accounts.

09.3 · Honest residue the metadata we do see

We publish the residual surface instead of denying it.

As a transport intermediary the relay sees routing while a message row exists, event timestamps, ciphertext sizes (bodies are padded to 256-byte blocks), coarse presence (a fuzzy online flag; last-seen rounded to five minutes), and chat membership. The zero-plaintext posture is structural and continuously verifiable — read-only production database access is available to qualified reviewers under NDA.

10 Verification

Machine-checked design.
Independent audit next.

The protocol design is formally verified with machine-checked models across five independent engines — Verifpal, ProVerif, CryptoVerif, Tamarin, and F*/DY* — the same class of tools and adversary model used in the published analyses of Signal’s PQXDH and SPQR. Eleven properties were verified, each additionally run with the protection removed as a negative control that must fail — so a proof means something. Among them:

A malicious or compelled server cannot impersonate a pinned contact — the pre-fix model re-discovers the attack.
Harvest-now-decrypt-later is closed: record traffic today, break all of X25519 later — still unreadable.
Even holding a broken Ed25519 key, a server cannot forge the identity — the trust root is ML-DSA-87.
Every message key stays secret unless both X25519 and ML-KEM-1024 fall — proved unbounded, per-message, in F*/DY*.
A server cannot silently downgrade the KEM suite — it is authenticated by the ML-DSA-87 signed prekey.

Stated plainly: these tools verify the protocol design, not the implementation source. An independent external audit of the implementation is the standard next step — the same step Signal and Apple took — and has not yet been performed. The full whitepaper, the formal-verification report with models and run-logs, and read-only production database access are available under NDA.

11 Comparison

Against the published state of the art.

Public status as of July 2026; primary sources below the table.

Messenger	PQ handshake	PQ ratchet	PQ signatures	PQ calls	Identity	In-chat payments
Qlavis · Messenger	✔ ML-KEM-1024 (FIPS 203)	✔ ML-KEM-1024 (NIST L5)	✔ ML-DSA-87 (FIPS 204)	✔ enforced server-side	✔ 12 words — no phone, no email	✔ Stellar + XRP Ledger
iMessage PQ3	✔ Kyber-1024	◐ Kyber-768 (rekey)	✗ classical (ECDSA)	✗	✗ Apple ID + phone	✗
Signal + SPQR	✔ Kyber-1024	✔ ML-KEM-768	✗ classical (Ed25519)	✗	✗ phone number	✗
SimpleX	✔ sntrup761	✔ double-KEM	✗ classical (Ed25519)	✗	✔ random ID	✗
WhatsApp	✗	✗	✗ classical	✗	✗ phone	✗

Three commitments not matched, to our knowledge, by any shipping competitor in 2026: ML-KEM-1024 in the ratchet, where Signal and Apple explicitly chose 768 for bandwidth; a post-quantum identity trust root, where every competitor pairs a post-quantum KEM with a classical signature; and post-quantum enforcement on calls at the signaling server, where every competitor leaves audio and video on classical SRTP.

Sources: security.apple.com/blog/imessage-pq3 (Feb 2024) · signal.org/blog/spqr (Oct 2025) · signal.org/docs/specifications/pqxdh · simplex.chat/blog (Mar 2024)

12 References

The standards this specification is built from.

NIST FIPS 203 — ML-KEM (Aug 2024) · NIST FIPS 204 — ML-DSA (Aug 2024) · FIPS 197 + SP 800-38D — AES-GCM
IETF RFC 7748 (X25519) · RFC 8032 (Ed25519) · RFC 5869 (HKDF) · RFC 2104 (HMAC) · RFC 8018 (PBKDF2) · RFC 6979 (deterministic ECDSA)
BIP39 · BIP32 · SLIP-0010 — deterministic key derivation
Signal specifications — PQXDH, the Double Ratchet, SPQR (signal.org/docs)
NSA CNSA 2.0 (Sep 2022) · Executive Order 14412 (Jun 2026): post-quantum key establishment by 2030, signatures by 2031

The full whitepaper, the formal-verification report, and read-only production database access — available to qualified investors, audit firms, and procurement teams under NDA: hello@qlavis.app