Matrix is an open, federated communication protocol used by Element, the French government's Tchap, the German military's BwMessenger, the Mozilla Foundation, and a growing number of organizations that want a self-hosted, end-to-end encrypted alternative to Slack, WhatsApp, or iMessage. The Matrix specification is maintained at matrix.org, governed by the Matrix.org Foundation, and the underlying cryptographic primitives are documented as Olm (for one-to-one chats) and Megolm (for group chats). Both Olm and Megolm rely on Curve25519 and Ed25519, two classical elliptic curve algorithms that are not quantum-resistant.
Matrix's federated architecture means the post-quantum migration is more complex than a simple library upgrade. There is no central rollout switch like Apple flipping iMessage to PQ3. Each homeserver, each client, each bridge to other networks needs to support the new primitives, and the federation must negotiate algorithms across versions. This article walks through the current Matrix cryptography, the post-quantum design considerations, and the work happening in the Matrix.org Foundation toward a quantum-safe future.
Olm: One-to-One Encryption
Olm is the protocol that protects messages between two specific Matrix users. It is heavily inspired by the Signal protocol — specifically the Signal X3DH key agreement and the Signal Double Ratchet for forward secrecy and post-compromise security. Olm was originally written in C++ by Matthew Hodgson and the Matrix.org team and ported to Rust as part of the vodozemac library.
The cryptographic primitives Olm uses are:
Curve25519 for the X3DH-style key agreement, where each user has a long-term identity key, a medium-term signed prekey, and a pool of one-time prekeys. New conversations consume one of the recipient's one-time prekeys and combine three or four DH operations to produce the initial root key.
Ed25519 for signing the medium-term signed prekey.
HKDF-SHA-256 for the ratchet key schedule.
AES-256-CBC plus HMAC-SHA-256 for the actual message authenticated encryption (a slight variation from Signal, which uses AES-CBC plus HMAC-SHA-256 in the same way).
The Double Ratchet means that every message advances both an asymmetric ratchet (a fresh DH exchange when the direction of communication flips) and a symmetric ratchet (deriving fresh per-message keys from the chain). After enough exchanges, compromising the long-term keys does not let an attacker decrypt past messages, and compromising one message key does not let them decrypt subsequent messages.
The quantum-vulnerable pieces are the Curve25519 DH operations and the Ed25519 signature on the signed prekey. Everything else (HKDF, HMAC, AES) is symmetric and quantum-resistant when used with adequate key sizes.
Megolm: Group Encryption
Olm scales poorly to group chats. A 100-person room would need 100 separate Olm sessions per sender, and every message would have to be encrypted 100 times. To solve this, Matrix uses Megolm, a sender-key protocol where each sender maintains a single ratcheting key and shares it with all room members. Each member then decrypts messages using the sender's chain key.
Megolm's setup uses Olm to deliver the initial Megolm session key from sender to each receiver. Once delivered, the sender ratchets the key forward independently, and receivers ratchet their copies as messages arrive. Forward secrecy is good (old chain keys are deleted) but post-compromise security is weaker than Olm because the sender does not refresh keys via DH on every message.
Periodic Megolm session rotation — typically every 100 messages or every week — limits the impact of a compromise. When the sender rotates, a new Megolm session is created and distributed via Olm to all members.
The quantum-vulnerable piece in Megolm is the Olm transport that delivers the session key. The Megolm chain itself is symmetric (HKDF + AES), so it is quantum-resistant. If the Olm transport is upgraded to a hybrid PQ X3DH, Megolm inherits the protection.
The Matrix Federation Layer
Matrix homeservers sign their messages and federation traffic with Ed25519 keys. The signing keys identify the homeserver to other homeservers and are used to verify the integrity of events that cross server boundaries. There is a separate notion of user device keys, which sign user identity claims and link Olm/Megolm sessions to specific devices.
For PQC, both layers need attention. The homeserver Ed25519 keys are fine for signing federation traffic against tampering today, but a future quantum attacker could forge homeserver signatures retroactively if the signed material is recorded. Hybrid signatures (Ed25519 + ML-DSA-65) protect against this.
User device signing keys play a critical role in Matrix's cross-signing system, where a user has a master signing key, a self-signing key, and a user-signing key. These let users vouch for their own devices and for other users' identities. Cross-signing trust is the foundation of Matrix's multi-device end-to-end story. Migrating it to hybrid PQ is necessary but tricky because the Ed25519 keys are baked into existing room state and can take years to age out.
What Matrix.org Has Said
The Matrix.org Foundation has acknowledged the post-quantum challenge in several blog posts and Foundation Open Tech Will conference talks. The general direction has been:
Step one is to wait for stable PQC primitives. With NIST FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA) finalized in August 2024, this milestone is reached.
Step two is to update the Olm/vodozemac libraries to support a hybrid X3DH-style key agreement. The natural design uses ML-KEM-768 + Curve25519, mirroring Signal's PQXDH. The Matrix MSC (Matrix Spec Change) process would document the new prekey types and session establishment.
Step three is to update the cross-signing keys to allow hybrid Ed25519 + ML-DSA signatures, with backward compatibility for older clients that only verify Ed25519.
Step four is to roll out homeserver federation signing upgrades, with a long deprecation window for older clients.
As of early 2026 the public MSCs for hybrid PQ Olm have been drafted and discussed in working groups. No production implementation has shipped. Element's iOS and Android clients use vodozemac, which is the natural place for the hybrid implementation to land.
Why Matrix Is Slower Than Signal
Signal flipped on PQXDH in September 2023 — two years ago — for all users globally. Apple iMessage rolled out PQ3 in February 2024 for all users. Why has Matrix not done the same?
The reason is federation. Signal and iMessage are centralized services with a single client codebase under one organization's control. They can ship a coordinated server-and-client update that switches everyone over within a release cycle. Matrix is a federation of independent homeservers, each running potentially different versions, and clients from a dozen vendors. A unilateral upgrade by one homeserver leaves it unable to communicate with users on older homeservers. The migration must be coordinated through the spec process and rolled out with version-negotiation.
This is not unique to Matrix. XMPP faces the same problem, as do email and SIP. Federation is wonderful for resisting central control and is painful for coordinated cryptographic upgrades.
What Hybrid Olm Would Look Like
A hybrid Olm session establishment would work like this. When Alice wants to start a session with Bob, she fetches Bob's keys from his homeserver: identity key (Curve25519 + ML-KEM-768 public), signed prekey (Curve25519 + ML-KEM-768 public, signed by identity), and a one-time prekey (Curve25519 + ML-KEM-768 public).
Alice generates her own ephemeral Curve25519 key and computes three Diffie-Hellman values:
DH1 = DH(Alice identity, Bob signed prekey) DH2 = DH(Alice ephemeral, Bob identity) DH3 = DH(Alice ephemeral, Bob signed prekey) DH4 = DH(Alice ephemeral, Bob one-time prekey) — if available
She also computes ML-KEM encapsulations against Bob's three KEM public keys, producing three ciphertexts and three shared secrets. The five (or four) DH outputs and three KEM outputs are concatenated and run through HKDF-SHA-256 to produce the root key.
The first message includes Alice's ephemeral Curve25519 key and the three ML-KEM ciphertexts. Bob decapsulates each ciphertext using his secret keys and reproduces the same root key. From there, the Double Ratchet proceeds as in classical Olm.
The size cost is real. Three ML-KEM-768 ciphertexts at 1088 bytes each is 3264 bytes, plus the public keys in the prekey bundle. A Matrix prekey bundle today is a few hundred bytes; a hybrid one is several kilobytes. Server storage and network bandwidth grow accordingly. For a busy homeserver with thousands of one-time prekeys per user, this adds up.
Implementation Status
vodozemac, the Rust port of Olm used by Element and other modern Matrix clients, is the natural home for the hybrid implementation. Its modular architecture should make adding ML-KEM-768 alongside Curve25519 reasonable. The challenge is the wire format: every Olm message header needs to indicate which version it is and which algorithms are in use.
The reference Matrix server, Synapse, would need to advertise PQ-capable users and store the larger prekey bundles. Server developers have noted in public discussions that storage scaling is a real concern.
Bridges (Matrix to Telegram, Matrix to IRC, etc.) inherit whatever cryptography they bridge from. Hybrid Olm only protects messages on the Matrix side.
High-Stakes Deployments
Matrix is used in real high-stakes deployments. Tchap is the official messenger of the French civil service. BwMessenger is for the German military. Several hospital chains in Germany and the UK use Matrix for clinical chat. These deployments cannot wait too long for hybrid PQ.
The harvest-now-decrypt-later threat is real for these users, even if it feels distant. A foreign intelligence service that captured a year of French civil service chat today could decrypt it in 2035 if a cryptographically-relevant quantum computer is available by then. We cover this scenario in Harvest Now, Decrypt Later.
The Verifiability Question
A useful property of Matrix is that the protocol is open and the major implementations are open source. Researchers, auditors, and customers can inspect the code that performs the cryptography. The vodozemac library used by Element clients is on GitHub at github.com/matrix-org/vodozemac. The Synapse server is on GitHub. The cross-signing implementation is documented in the spec.
For PQ migration, this open-source posture matters. Government and military deployments often require independent code review of cryptographic primitives. The hybrid PQ Olm code, when it lands, will be inspectable. Auditors can verify that the ML-KEM operations are implemented correctly, that the key derivations match the spec, that the Curve25519 component is genuinely combined with the ML-KEM component (rather than one of them being silently bypassed). This is harder to do for closed-source messengers like iMessage or WhatsApp.
The flip side is that openness alone does not guarantee security. Bugs slip past public review. Side-channels are easy to overlook. The Matrix.org Foundation will need external audits of the hybrid PQ Olm implementation before it ships, particularly for the ML-KEM constant-time discipline. Recent published research on Kyber side-channels (Ravi et al. 2022, Pessl and Prokop 2021) shows that masking of the ML-KEM decryption step is non-trivial, and a naive implementation can leak the secret key through power or timing analysis. Implementation correctness matters as much as protocol correctness.
QNSQY's Connection
QNSQY uses the same hybrid principle for file encryption that the Matrix hybrid Olm design will use for messaging: ML-KEM combined with X25519 (Matrix calls it Curve25519, the same curve in different encoding), then HKDF-SHA-256 for key derivation. See Hybrid Encryption and ML-KEM Explained for the rationale.
Frequently Asked Questions
Can I make my Matrix room post-quantum today?
Not directly. The Olm/Megolm libraries do not yet have hybrid PQ support in production. You can add a layer of file encryption on top using QNSQY for sensitive attachments, which is post-quantum at the file level.
Will all Matrix clients need to update?
Yes. Hybrid Olm is incompatible with classical Olm at the protocol level. Old clients will see PQ messages as undecryptable, and PQ clients will fall back to classical when talking to old peers — which leaves those conversations quantum-vulnerable.
Is Element's encryption broken now?
No. Olm and Megolm are well-designed and currently secure against any adversary without a quantum computer. The risk is future decryption of recorded traffic.
How long will the Matrix migration take?
Federated protocols historically take five to ten years to roll out major upgrades. The Matrix.org Foundation has signaled it is treating PQ as a near-term priority but no firm timeline is public.
What about Megolm group encryption?
Megolm itself is symmetric and quantum-resistant. The vulnerable step is the Olm channel that delivers Megolm session keys. Once Olm is hybrid PQ, Megolm sessions inherit the protection.
Sources
- Matrix.org Foundation. "Matrix Specification." https://spec.matrix.org/
- Matrix.org. "Olm: A Cryptographic Ratchet." https://gitlab.matrix.org/matrix-org/olm
- Matrix.org. "Megolm group ratchet." https://gitlab.matrix.org/matrix-org/olm/-/blob/master/docs/megolm.md
- Matrix.org. "vodozemac: A Rust Implementation of Olm and Megolm." https://github.com/matrix-org/vodozemac
- NIST FIPS 203. "Module-Lattice-Based Key-Encapsulation Mechanism Standard." August 2024. https://csrc.nist.gov/pubs/fips/203/final
- NIST FIPS 204. "Module-Lattice-Based Digital Signature Standard." August 2024. https://csrc.nist.gov/pubs/fips/204/final
- Signal Foundation. "The PQXDH Key Agreement Protocol." Signal blog, September 19, 2023. https://signal.org/blog/pqxdh/
Related Articles
- Signal PQXDH Deep Dive
- XMPP and OMEMO: PQC Path Forward
- MLS Protocol Deep Dive
- Hybrid Encryption: Why Combining Old and New Crypto Is Stronger
- Harvest Now, Decrypt Later
Protect Your Data Before Q-Day Arrives
QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.