Signal Protocol vs MLS: the bytes on the wire, the trade offs that matter

I picked MLS for UmbrellaX, and I respect Signal Protocol enough that I spent two months working through the decision before I committed. Both protocols solve the one to one end to end encryption problem to a comparable standard. They diverge sharply on groups, where Signal Protocol layers pairwise sessions and MLS uses a tree. They have taken different routes to post quantum. The choice for a new messenger in 2026 is decided by which trade off you would rather inherit, not by which protocol is “better” in some abstract sense.

Below: the one to one case where it is mostly a coin flip, the group case where MLS is built for the job, the post quantum question both teams just answered differently, the adoption picture, and the places Signal Protocol still wins.

1. The one to one case

When I sat down and read both specs back to back, the first thing that struck me is how similar the destinations are. Both protocols handshake to a shared secret, then ratchet keys forward from there. The way each gets there is different. The end position is the same.

The Signal Protocol uses X3DH, an Extended Triple Diffie Hellman that mixes my long term identity key, the recipient’s long term key, the recipient’s signed prekey, and the recipient’s one time prekey to compute a shared secret nobody else can derive. From that secret the Double Ratchet starts producing per message keys. Every send rolls a KDF chain forward; every reply rolls a Diffie Hellman ratchet that mixes fresh entropy in. I have a lot of respect for X3DH as a piece of cryptographic engineering. It solves the asynchronous contact problem cleanly and I have not seen anyone improve on the basic idea in twelve years.

MLS handles the same case as a degenerate group of two. The recipient publishes a KeyPackage, the sender pulls it, generates a Welcome message that establishes initial group state, and the per message keys come out of the TreeKEM key schedule applied to a two leaf tree. The handshake is shaped differently but the ending position is the same: a shared secret, a ratchet with forward secrecy, post compromise security after the next key rotation. I implemented both stacks in scratch code last year before I committed UmbrellaX to MLS, and on the one to one case the differences I saw in the field were aesthetic, not security bearing.

For one to one the choice is mostly aesthetic and operational. My honest take: I do not lose sleep over which one an app for pairs only picks. The Signal Protocol stack is simpler to read and implement. A careful implementer can ship a Signal Protocol library for pairs in a long weekend. MLS gives you a unified protocol surface that handles the pair case as a special case of the group case, which matters once you also need groups but is overhead if you do not. I picked MLS for UmbrellaX because the rest of what I was building needed groups, and I was not going to run two protocols side by side just to optimise the pair path.

The cryptographic strength is comparable. The CRYPTO 2022 paper by Alwen, Coretti and Dodis gives the most thorough security analysis of the Double Ratchet to date and shows the algorithm is sound under standard assumptions. RFC 9420 was designed to be formally analysable from the outset, and large parts of the protocol were checked with formal models before any production implementation existed. My reading of both bodies of work is that for pairs neither stack is the wrong call. Both are honest engineering and I would happily build on either if conversations between two people were the only requirement on the table.

2. Groups

This is where the protocols genuinely diverge, and this is where I made my call. I want to walk through the byte level reality, because the abstract O(N) versus O(log N) shorthand undersells what actually happens on a real group.

The Signal Protocol does not, strictly, have a group cryptographic primitive. Group support is application layer. There are N pairwise Signal sessions, one for each pair of members, plus a Sender Key, a symmetric chain key that the sender broadcasts to the group. To broadcast the Sender Key the sender encrypts it once for each recipient using their pairwise Signal session. When a member is added or removed, the Sender Key rotates, and the new key has to reach every remaining member through their pairwise channel. That is N encryptions per state change. At 100 members it is 100 encryptions; at 5,000 members it is 5,000 encryptions per join, leave, or rotation event. I have written this kind of group keying layer before, and the cost is not theoretical.

MLS does not work that way. The group is one cryptographic object, a TreeKEM tree where each leaf is a member’s keypair and each internal node holds a key derived from its two children’s keys. A Commit message updates the path from a leaf to the root. The committer encrypts the new path key to each subtree along the path; every other member applies the commit by rederiving its view of the tree. This is O(log N) operations. On a 5,000 member tree the path is 13 levels deep, one Commit message contains roughly 13 ciphertexts, and every member can apply it. When I worked through the math on a 200,000 member group I came out at 18 internal node updates per commit, which is the kind of constant a system can actually carry.

Walk through what happens when a 200 member group adds a new member. Signal Protocol: the next sender has to encrypt the rotated Sender Key to 200 individual recipients, one at a time, via 200 pairwise sessions. That is 200 ciphertexts on the wire to land one new key. MLS: the committer broadcasts one Commit message; every member applies it locally. MLS bandwidth grows logarithmically with group size; Signal Protocol’s grows linearly. From where I sit as someone who has to size a backend for the next decade, those two curves go to very different places.

Forward secrecy properties also differ, and this is the bit I dwell on the most. In Signal Protocol’s group model the Sender Key chain is a symmetric KDF chain. Forward secrecy is good. The post compromise property depends on whoever sends next pulling fresh Diffie Hellman entropy through the underlying pairwise sessions, which is mediated by the Double Ratchets at the pair level. In MLS, every Commit produces a fresh root key and destroys the previous one; post compromise security falls out of the protocol structure cleanly, regardless of who sends next. My read is that the MLS post compromise story is the cleaner one for a Tier D threat model, where I cannot rely on any particular member sending soon.

The IETF MLS Working Group had this in mind from the first whiteboard. The named design goals in RFC 9420 are explicit: groups as a first class primitive, efficient asynchronous membership change, and post compromise security suitable for formal analysis. They built for the group case from day one. The Signal Protocol grew up in the field handling pairs and got groups later as a layer on top. Both decisions made sense in their context, and I am not throwing rocks at Trevor or Moxie. They built for what they were facing.

When I sat down to size UmbrellaX for groups of 200,000 members, the Signal Protocol approach simply did not fit. 200,000 pairwise encryptions for one membership change is not an implementation detail that can be optimised away. It is a property of the protocol. I needed a 200,000 member ceiling because protest coordination broadcast lists in countries where I expect UmbrellaX to ship hit those numbers, and because journalism source protection groups occasionally do too. MLS was the right base for what I was building, and I went with it on day one.

3. Post quantum

When Signal published the SPQR paper on 2 October 2025 I sat down and read it cover to cover. I will be specific about what I think they got right and what my call was when I sized UmbrellaX for the same threat.

Signal announced the Triple Ratchet, which is the Double Ratchet plus the Sparse Post Quantum Ratchet (SPQR) plus a key derivation function that mixes their outputs into a single hybrid key. SPQR runs in parallel with the Double Ratchet and uses ML KEM 768 for post quantum key encapsulation. ML KEM ciphertexts are large (well over a kilobyte each), and a messenger cannot carry a kilobyte on every message without measurable bandwidth pain, so SPQR uses erasure coded chunking. Break the ciphertext into small pieces, ride them along over multiple messages, reconstruct the key once a threshold of pieces has arrived. The Triple Ratchet was designed with researchers from PQShield, Japan’s AIST, and New York University, formally verified with ProVerif and F*, and the underlying papers shipped at Eurocrypt 2025 and USENIX Security 2025. Sessions upgrade automatically when both endpoints support the Triple Ratchet, with backward compatibility downgrades for legacy peers. I respect the engineering on every line of that paragraph. The erasure coded chunking in particular is a clean answer to a constraint I have spent time on myself.

MLS post quantum extensions take a different shape. The TreeKEM key schedule is naturally hybrid friendly. Encapsulate to each path key with ML KEM in parallel with the classical X25519 encapsulation, mix both into the path key derivation, and the rest of the protocol stays the same shape. I run hybrid X25519 plus ML KEM 768 on top of MLS in UmbrellaX production today. I went hybrid because pure post quantum still spooks me on key sizes and field history, and I wanted an attacker to have to break both the classical and the lattice cryptography to break a session.

Both designs answer the same threat: harvest now, decrypt later. Both are formally verifiable. Both use ML KEM 768. Both mix classical and post quantum agreement so an attacker has to break both. The difference is operational, and I think both teams made the call that fit their constraints.

Signal’s answer protects an existing surface, roughly 3 billion users between WhatsApp, Signal, and the Signal Protocol descendants, without a flag day, without forcing every implementer to upgrade simultaneously, and with graceful downgrade on every endpoint. That is a big infrastructure win and it is genuine engineering. If I were sitting in Meredith Whittaker’s seat I would have made the same call: protect what is shipped, retrofit cleanly, do not break a billion users’ messengers in one go.

MLS’s answer is built into the protocol from day one and does not need retrofitting. I shipped MLS PQ as the default in UmbrellaX because I did not have to retrofit anything. Signal had a surface with billions of users to protect; I had a clean slate. The path each side took reflects the constraint each side actually faced. I do not want any of my users’ messages from 2026 to be readable in 2046 because some quantum computer turned up in 2040, and that is the timer the hybrid agreement removes.

4. Adoption surface

I track this picture monthly because it is what tells me whether I am picking a stack that will be a footnote in five years or a default. Today the picture is split clean.

Signal Protocol is in WhatsApp, Signal itself, and (via a proprietary descendant) iMessage. That is on the order of 3 billion people sending messages on Signal Protocol or its descendants every day. I will say this plainly: nothing else competes with that scale of deployment, and a new messenger pretending the Signal Protocol is in any way “yesterday’s stack” is selling something I would not buy.

MLS is in Webex (which started on a draft version of MLS for Zero Trust Security and is upgrading to the RFC version), in Google Messages over RCS (Google announced MLS adoption for RCS in July 2023), in Apple Messages over RCS 3.0 (announced March 2025), in Matrix (declared MLS migration), and in any new messenger built since RFC 9420 landed. AWS Labs publishes a Rust reference implementation under a permissive licence. The IETF MLS Working Group continues to develop extensions.

My read of the next two years is that the pivot here is RCS. Once Apple and Google both ship MLS as the underlying E2EE for cross platform RCS, MLS becomes the default for the mobile messaging surface across platforms, the same way the Signal Protocol became the default after Open Whisper Systems’ work on Android and iOS. I would not be surprised if MLS overtakes the Signal Protocol on raw user count by 2028 simply on the back of RCS. I would also not bet against the Signal Foundation continuing to ship innovations on the original protocol the whole way.

For a new messenger in 2026, MLS is the standards track choice and I picked it on those grounds. For a maintainer of an existing protocol surface with 3 billion users, the Signal Protocol, now extended to the Triple Ratchet, is the right place to keep building, and if I were maintaining that surface I would not hop to MLS just because the standards track exists. Both choices are honest engineering, sized to different constraints.

5. Where Signal Protocol still wins

I am going to be specific about the three places where I think Signal Protocol is still the better answer, because I respect the work and I am not going to pretend MLS has won everything.

A decade of adversarial field exposure. Since 2013 the Signal Protocol has been carrying real traffic for billions of users. Every weakness an adversary could find was something an adversary had time to find. MLS has had two and a half years in the field as of May 2026. The cryptographic strength is comparable on paper; the operational confidence is not yet equal, and I am not going to pretend it is. If your threat model places the highest weight on time in field, my honest answer is that the Signal Protocol still wins on this dimension. UmbrellaX has zero hours of carrying real traffic at the time of this writing, and I will not lie about that.

Implementation simplicity for pairs. A clean Signal Protocol stack for messaging between two people is something a careful implementer can read and ship in a long weekend. MLS has more moving parts because it is doing more (groups as a first class primitive). For a use case that is genuinely about pairs and where bringing in a full MLS implementation is a heavier lift than the problem requires, my position is that the Signal Protocol is the lighter answer and I would tell a friend building that product to use it.

Diversity of mature implementations. libsignal exists in C, Java, and Swift, with Rust and TypeScript ports, and Signal Foundation maintains the canonical implementations. There are more than a decade of accumulated open source production stories baked into them. MLS implementations exist from AWS Labs, OpenMLS, and Cisco, and they are good, but the ecosystem is younger and the production stories are still accumulating. I have read code in both ecosystems and the Signal one is still the more battle scarred, by a margin that matters if you are debugging at 3am.

The Triple Ratchet announcement in October 2025 is the cleanest evidence that Signal’s team is still actively designing on the original protocol, not transitioning away from it. Picking the Signal Protocol in 2026 is not picking a legacy, and I want to say that out loud because I have heard the opposite framing in the privacy press and I do not agree with it.

Which to pick

Two months working through this in 2024 and I came out at the rule I am about to give you. I stand behind that call now.

Pick MLS if you are building a new messenger that needs groups as a first class primitive. The IETF standardisation, the formal verification work, the tree based group keying, and the permissive open source reference implementations together make MLS the correct base for new construction in my view. I run MLS on UmbrellaX for these reasons and I do not regret the choice.

Pick the Signal Protocol if you are extending an existing deployment with a billion user surface, or if your use case is genuinely about pairs and the implementation simplicity matters more than the unified protocol surface. The Triple Ratchet announcement shows that Signal’s team is still innovating on the protocol, the implementations are mature, and the field exposure is unmatched. My honest advice is the same as I would give a friend: do not switch off the Signal Protocol just because MLS exists. Switch when your use case actually demands what MLS gives you.

Both are honest engineering. The right call for a builder depends on what you are actually building, not on which protocol gets praised more in the privacy press. I picked MLS for what I am building. I would respect a builder who picked the Signal Protocol for a different problem and looked me in the eye and told me why.

I’m Kirill Abramov, founder and CEO of UmbrellaX TOO, a privacy first messenger company registered in Kazakhstan, outside the Five Eyes alliance. I designed UmbrellaX’s cryptographic stack on MLS plus post quantum hardening, and I write about end to end encryption, post quantum cryptography, and the regulatory pressure on private communication. More about my work and why I run UmbrellaX from Kazakhstan: umbrellax.io/about.