Open Signal, then WhatsApp, then Element, then a cross-platform RCS chat between an Android phone and an iPhone. Each one shows a little lock and promises end-to-end encryption. So are they all running the same math under the hood? Partly. They share goals and a few building blocks, but the machinery differs a lot, especially once a chat has more than two people in it.
This is part one of our protocols week. Today we draw the map: the Signal Protocol, Matrix's Olm and Megolm, and the IETF's Messaging Layer Security (MLS). We'll look at what each one was built to do, how it handles groups, how ready it is for quantum computers, and which problems none of them solve.
What every design is chasing
Every secure messenger wants two basics: confidentiality (only the people in the chat can read it) and authentication (you know who sent what). The modern designs then add two time-based guarantees.
- Forward secrecy (FS): if someone steals your keys next month, they still can't read what you sent last month.
- Post-compromise security (PCS): if someone steals your keys today, the chat recovers, and once fresh keys are in use the thief is locked out again.
Signal's post on its post-quantum ratchet (Signal) describes the pair as mirror images: forward secrecy shields what was sent before a key theft, and post-compromise security shields what is sent after it. If you want the gentle version first, start with our primer, End-to-end encryption, explained like you're busy.
Most of the tools here rely on Diffie-Hellman (DH): two devices each combine their own secret with the other side's public value and arrive at the same shared secret, even though everything they exchanged was public. Keep that in mind, because quantum computers change the picture.
The Signal Protocol: the one-to-one template
The Signal Protocol is what Signal uses and what WhatsApp built on. It has two phases.
Starting a chat. Your phone fetches a bundle of public keys that your contact uploaded earlier, so the first message can go out even while they're offline. The original handshake was called X3DH. Signal later upgraded it to PQXDH, which mixes a post-quantum key encapsulation mechanism (KEM) into the start of the session. A KEM does the job DH does, a different way: one side uses the other's public key to lock up a fresh random secret and sends it over. The point is "harvest now, decrypt later": someone recording traffic today shouldn't be able to unlock it with a future quantum machine.
Keeping it going. After the handshake comes the Double Ratchet. Two ratchets turn together:
symmetric ratchet: chain key -> message key 1, message key 2, ... (one key per message)
DH ratchet: every reply carries a new DH public key -> new chain keys
The symmetric part gives every message its own key and throws old ones away (that's forward secrecy). The DH part injects fresh randomness each time the conversation changes direction (that's healing, or PCS). The spec also explains how to handle messages that arrive late or out of order by holding on to skipped keys for a while.
The post-quantum layer. In October 2025 Signal introduced SPQR, the Sparse Post-Quantum Ratchet. It uses ML-KEM 768, the NIST-standardized post-quantum KEM, and runs next to the Double Ratchet rather than replacing it. Keys from both are mixed together, so cracking just one of the two layers gets an attacker nowhere. Signal calls the result the Triple Ratchet.
Why "sparse"? Size. An elliptic-curve public key is 32 bytes, while an ML-KEM 768 encapsulation key is 1,184 bytes and its ciphertext 1,088 bytes, per Signal. Attaching that to every message would bloat traffic. So SPQR slices the material into chunks (using erasure codes, so a few lost messages don't stall it) and spreads them across many messages, completing a post-quantum step every so often rather than every time. PQShield, which co-designed the protocol, walks through the same design from the outside.
Signal also wrote that it checks the design with ProVerif models and translates its Rust code to the F* proof language with the hax tool on every CI run. When it announced SPQR, Signal described a gradual rollout that becomes mandatory once all supported clients understand it; we didn't find an official Signal update saying that switch is complete for every chat.
Groups. Signal and WhatsApp handle groups with Sender Keys. Each member creates one sending key, shares it with every other member over the existing one-to-one encrypted channels, then encrypts each group message once and lets the server fan it out. It's efficient and, according to the Send and Pretend paper presented at USENIX Security 2026, copes with groups of roughly 1,000 people. The catch: changing membership means handing out fresh keys over many pairwise links, and the healing story for groups is weaker than for one-to-one chats.
Matrix: the same ideas, on a federated network
Matrix took the Double Ratchet and adapted it to a very different setting. The Olm specification opens by describing Olm as an implementation of the Double Ratchet, started with a triple Diffie-Hellman (3DH) handshake over Curve25519. Olm protects device-to-device channels.
For rooms, Matrix uses Megolm. Each sender keeps an outbound session whose key moves forward with every message, and it shares that session's key with the other participants' devices over Olm. Conceptually it sits close to Sender Keys: one encryption per message, keys distributed pairwise.
The real difference is architecture. Signal and WhatsApp each run one service. In Matrix, anyone can run a homeserver, users pick their own client apps, and a single room can stretch across many servers run by different organizations. Device lists and room keys have to travel through that federation, which makes key management harder and gives each server operator a view of who is in which room.
The main implementation today is vodozemac, written in Rust. When Matrix.org deprecated libolm, the original C/C++ library, in 2024, it pointed developers to vodozemac as the successor. On post-quantum: we found no primary source saying Matrix encryption is post-quantum today. A pull request adding PQXDH to vodozemac exists, but it's an open draft, and a project comment from June 2026 says the work is on hold pending funding.
One more thing about vodozemac: in 2026 it was the subject of a very public argument between a security researcher and the Matrix.org Foundation. That's Wednesday's story.
MLS: designed for big groups from day one
Messaging Layer Security is the IETF's answer to a simple question: what if groups were the main case rather than an afterthought? RFC 9420, published in July 2023 on the Standards Track, describes itself in its abstract as providing "asynchronous group key establishment with forward secrecy (FS) and post-compromise security (PCS) for groups in size ranging from two to thousands."
The trick is the ratchet tree. Picture a family tree with members as the leaves. Each branch point holds a key that only the members below it know, and the top of the tree feeds the group's shared secret. When one person updates their key or someone leaves, only the branches on the path from that leaf to the top need new keys. For a group of n people, that's roughly log(n) operations instead of n. In a 1,000-person group, that's about 10 steps rather than 1,000.
Every change (add, remove, update) happens as a numbered step, or "epoch", that all members agree on, so the whole group moves forward together and gets PCS for groups, not just pairs.
The companion RFC 9750 (April 2025, Informational) describes the architecture around the protocol. It splits the service side into an Authentication Service, which vouches that a key really belongs to a given person or device, and a Delivery Service, which stores and forwards messages and key packages. It's frank that a lot is left to the application, including how identities are checked and how much those services are trusted.
Where you'll meet MLS:
- RCS between Android and iPhone. The GSMA's end-to-end encryption specification for RCS (RCC.16, version 3.0) builds encryption for both one-to-one and group chats on MLS (RFC 9420), as the GSMA also explained when it announced the specs in 2025. Encrypted chats between Android and iPhone started rolling out in beta on May 11, 2026, according to Apple, and Apple's support page still labels it beta. Friday's post covers it.
- Discord calls. Discord's DAVE protocol uses MLS for the group key exchange in its end-to-end encrypted voice and video calls, which are now on by default except in Stage channels. Text chats aren't covered, and Discord says it has no plans to change that (BleepingComputer).
- Wire, which we noted last week.
Post-quantum MLS is in progress, not done. The cipher suites registered in RFC 9420 are classical. An IETF draft defining ML-KEM-based hybrid and pure post-quantum suites, plus ML-DSA signature suites, has been sent to the IESG for publication, but it is still a draft, not an RFC.
What the protocol doesn't fix
All three designs can be implemented perfectly and still leave gaps. Three matter for everyday users.
Is that really your friend's key? End-to-end encryption assumes you have the right public key for the other person. A compromised or coerced server could hand you an attacker's key instead. Comparing safety numbers in person was the classic check, and almost nobody does it. Signal now offers Automatic Key Verification, built on key transparency: a public directory of which key belongs to which account that anyone's app can check, kept as a Merkle-tree map so tampering shows up. According to Trail of Bits, which runs one of three auditors (the others are run by Signal and Cloudflare), clients need fresh signatures from all three within the past seven days. That means a fully malicious server could show different people different views of the directory for at most about a week before apps start warning. In Signal, the setting sits under Settings > Privacy > Advanced.
Is everyone in the group seeing the same chat? The Send and Pretend researchers showed that in WhatsApp, Signal, iMessage and Threema, a group member acting in bad faith can leave messages out, reorder them or send different versions to different people (polls included) without the others noticing. This isn't a break of the encryption, and an outsider can't do it; it needs someone already in the group. The paper also notes that MLS's transcript guarantees cover the group's handshake and membership state, not the ordinary messages. Vendor reactions were mixed: heise reported that none announced a fundamental protocol fix, with Meta planning poll changes and Signal saying it would tackle the issue during bigger group-chat work.
Who's talking to whom? End-to-end encryption hides the content, not the metadata: who you message, when, how often, from where. That varies more between apps than the crypto does. Our messenger checklist covers how messengers differ.
Side by side
| Signal Protocol | Matrix (Olm + Megolm) | MLS (RFC 9420) | |
|---|---|---|---|
| Starting a chat | PQXDH (classical DH plus ML-KEM) | 3DH over Curve25519 | Key packages fetched from a Delivery Service |
| Ongoing keys | Double Ratchet, plus SPQR (Triple Ratchet) | Olm for devices (Double Ratchet), Megolm for rooms | Epochs on a ratchet tree |
| Groups | Sender Keys over pairwise channels | Megolm sessions shared over Olm | Native, roughly log(n) cost per change |
| Post-quantum | Yes: PQXDH and SPQR | Not yet; PQXDH work is a draft on hold | Classical suites in the RFC; PQ suites still an IETF draft |
| Standardization | Open specs from Signal, not an IETF standard | Open spec run by the Matrix.org Foundation | IETF Standards Track RFC |
| Where you'll see it | Signal, WhatsApp | Element and other Matrix apps, government messengers | Encrypted RCS, Discord calls, Wire |
For a closed-source point of comparison, Apple's iMessage moved to its own PQ3 protocol in 2024, which adds post-quantum keys at setup and periodically rekeys during the conversation.
Why the differences matter
For people using these apps, the protocol name on the box matters less than you'd think. Signal and WhatsApp share a core protocol; the differences come from defaults, backups, metadata and whether key verification is available and easy. Some apps now offer automatic key verification, which confirms that the key your app received matches the one publicly listed for that account. It doesn't prove the other person's device is uncompromised, and it can't tell whether a group member is acting in good faith. The lock icon doesn't cover that either: it says nothing about whether someone inside a group is playing games.
On the building side, security engineers largely agree on the basics. Cryptographers have long advised against home-made protocols, so most teams build on a published one that fits their shape: one-to-one, federated or large groups. Post-quantum upgrades and key transparency are increasingly treated as part of the product rather than optional extras, and published protocols win partly because outsiders can review them. Open standards also matter for regulators, as Friday's post on interoperability will show.
Follow the series: on Wednesday, we look at why European governments are moving their staff onto Matrix, and what happened when a researcher went public with bugs in its crypto library. Friday asks whether rival apps can talk to each other without losing encryption. Grab the RSS feed, and if you spot a technical error, tell us.