Why was Messaging Layer Security (RFC 9420) standardized to replace pairwise Double Ratchet and Sender Keys in large groups?

Legacy end-to-end encrypted messaging protocols (such as Signal and WhatsApp pairwise Double Ratchets or Matrix Megolm) scale linearly or quadratically with group size. In a group of N members, adding, removing, or re-keying a participant requires O(N) pairwise encrypted messages or O(N) public key operations. In enterprise messaging channels (Slack, Discord, or large WhatsApp groups of 10,000+ users), an update triggered an O(N^2) network storm that overwhelmed mobile bandwidth. Ratified by the IETF in July 2023, RFC 9420 introduces TreeKEM, a balanced binary ratchet tree where group state updates scale logarithmically at O(log N). A group of 50,000 members requires only ~16 public key encryptions per update instead of 50,000.

How does TreeKEM use the Direct Path and Copath Resolution to update group secrets efficiently?

In a TreeKEM tree, each member occupies a leaf node containing their individual identity and HPKE keypair. Every intermediate parent node up to the root represents a shared HPKE keypair. When a member (e.g. Alice) performs an update, she generates a new leaf secret and derives new keypairs along her "direct path" (all ancestor nodes from her leaf to the root). To deliver these new keys to all other group members without revealing them to unauthorized parties, Alice computes the "copath resolution" of each direct path node (the list of non-blank sibling subtrees). She encrypts each node secret to the public keys of its copath using Hybrid Public Key Encryption (HPKE, RFC 9180). Because tree height is log2(N), only O(log N) ciphertexts are generated.

What is the distinction between Forward Secrecy (FS) and Post-Compromise Security (PCS) in MLS?

Forward Secrecy (FS) guarantees that an adversary who compromises a member device or secret key material at epoch E cannot decrypt any messages transmitted in earlier epochs (epochs < E). MLS achieves FS by ratcheting the application encryption secrets per message and deleting old keys immediately. Post-Compromise Security (PCS, also known as future secrecy or self-healing) guarantees that if an adversary compromises all key material on a member device at epoch E, the group can heal itself: as soon as the compromised member (or any other member) issues an Update commit in epoch E+1, a fresh root secret is established. Because the adversary does not possess the private keys of the copath nodes, they cannot decrypt the new direct path secrets, completely locking them out of all epochs >= E+1.

What is a "Blank Node" in TreeKEM and why is it essential when removing a member?

When a member is removed from an MLS group, the member must not have access to any future group secrets. The removing member evicts the target by "blanking" (deleting the key material of) the target leaf and all of its ancestor nodes up to the root. A blank node has no public or private key. During subsequent updates, the copath resolution algorithm skips blank nodes and descends into their populated children, collecting their non-blank descendant keys. This allows the tree to continue functioning without requiring an immediate, expensive full-tree rebalancing, preserving O(log N) scalability during membership turnover.

How does the MLS Delivery Service (DS) function as an untrusted intermediary?

Unlike centralized messaging architectures where servers have access to plaintext or TLS session keys, the MLS Delivery Service (DS) is strictly zero-trust. Its only responsibilities are (1) storing public KeyPackages for new user discovery, (2) providing a consistent linear ordering of Commit messages, and (3) broadcasting MLS messages to connected clients. All content is encrypted end-to-end via HPKE and AES-128-GCM. Group integrity is cryptographically guaranteed by Parent Hashes and Confirmation Tags: if a malicious DS injects, modifies, or omits a node in the ratchet tree, clients detect the signature and transcript hash mismatch and reject the commit.

What is the function of the Parent Hash in RFC 9420?

A subtle vulnerability in early tree-based key agreement protocols was the "tree-signing" problem, where a malicious delivery service or insider could splice or substitute unverified parent keys into the tree. RFC 9420 solves this with the Parent Hash extension: every parent node includes a parent_hash attribute that binds the node to its parent in the direct path, chaining from the root down to the leaf node signature. This provides cryptographic non-repudiation: a committer signs the parent hash chain in their leaf credential, making it mathematically impossible for an untrusted Delivery Service to tamper with intermediate public keys without breaking the committer leaf signature.

Verified Specification | Standardized Formulas | Instant Precision

Secure & Private (Zero Data Retention) Free Access • No Sign-Up

IETF RFC 9420 (July 2023) TreeKEM Binary Ratchet HPKE (RFC 9180) Post-Compromise Security

MLS (Messaging Layer Security, RFC 9420) & TreeKEM Architecture Studio

An architectural workbench and interactive simulator for the modern IETF standard in End-to-End Encrypted (E2EE) group messaging. Explore TreeKEM binary ratchet trees, direct path key rotations, copath resolutions, parent hashing, and unmerged leaves. Dissect Forward Secrecy (FS) and Post-Compromise Security (PCS), and synthesize production OpenMLS Rust and Go implementations.

8 Members

Active Tree Capacity

O(log N) = 3

TreeKEM Update Cost

Epoch 4

Group State Epoch

MLS_128_DHKEMX25519

HPKE Cipher Suite

ACTIVE (HEALED)

Post-Compromise State

Interactive TreeKEM Binary Ratchet Tree Visualizer

TreeKEM organizes group participants into the leaves of a balanced binary tree. Updating a member's key rotates only the ancestor nodes along the member's direct path up to the root, encrypting new node secrets to the copath resolution using HPKE in (O(log N)) steps.

Active Leaf (Member) Parent Node (HPKE Keypair) Copath Resolution Node Blanked Node (Post-Removal) Compromised / Adversary

TreeKEM Cryptographic Operations Log

Tree initialized with 8 members. Click 'Alice Key Update' to observe Direct Path & Copath computation...

MLS Key Schedule & Epoch Secret Derivation Pipeline

Each commit advances the group to a new epoch. The new epoch secret is derived from the previous epoch's init_secret combined with the commit_secret extracted from the root node of the TreeKEM ratchet tree.

EPOCH TRANSITION EQUATIONS (RFC 9420 SECTION 8) HKDF SHA-256

joiner_secret = HKDF-Extract(commit_secret, init_secret[epoch - 1])
welcome_secret = HKDF-Expand-Label(joiner_secret, "welcome", "", 32)
epoch_secret = HKDF-Expand-Label(joiner_secret, "epoch", GroupContext, 32)
└── encryption_secret → Sender Data Ratchet (AES-128-GCM Payload Keys)
└── confirmation_key → HMAC Confirmation Tag on Commits
└── membership_key → Message Framing Authentication
└── resumption_psk → Post-Shared Key for Epoch Reconnects
└── next init_secret → Input Secret for Epoch [epoch + 1]

Epoch Secret Name	Derivation Label	Output Length	Security Function & Purpose
joiner_secret	`"joiner"`	32 Bytes	Bridge secret shared between existing members and newly joined members via Welcome message.
epoch_secret	`"epoch"`	32 Bytes	Root master secret for the current epoch, bound to the serialized `GroupContext` transcript.
encryption_secret	`"encryption"`	32 Bytes	Seed for the per-sender symmetric ratchet. Ratchets forward per message to guarantee Forward Secrecy.
confirmation_key	`"confirm"`	32 Bytes	Computes the HMAC confirmation tag verifying that all members agree on the exact same tree state.
init_secret	`"init"`	32 Bytes	Passed forward into the next epoch's HKDF-Extract stage, chaining epoch history cryptographically.

MLS Framing, Proposals, Commits & Welcome Wire Anatomy

MLS group changes follow a two-phase lifecycle: participants broadcast Proposals (Add, Remove, Update, PreSharedKey), and any member can subsequently aggregate proposals into an atomic Commit message containing the new TreeKEM UpdatePath.

Protocol Architecture Comparison: MLS vs Signal vs Matrix Megolm

How Messaging Layer Security compares to the historic industry standards across mathematical scalability, forward secrecy, and post-compromise security guarantees.

Protocol Characteristic	MLS (RFC 9420)	Signal (Sender Keys)	Matrix (Megolm Ratchet)
Group Key Topology	TreeKEM Binary Ratchet	Pairwise Double Ratchet + Sender Keys	Pairwise Olm + Shared Megolm Session
Member Update Bandwidth	O(log N) — Logarithmic	O(N) — Linear	O(N) — Linear
Forward Secrecy (FS)	Strict Per-Message FS	Strict Per-Message FS	Ratchet Advance (Weak FS)
Post-Compromise Security (PCS)	Instant on Member Update	Requires Full Key Re-distribution	No Built-In PCS
Maximum Practical Group Size	50,000+ Members	~1,000 Members (Bandwidth bound)	~1,000 Members (Session bound)
Untrusted Delivery Service	Cryptographically Enforced (Parent Hash)	Server is trusted for delivery ordering	Server is trusted for key forwarding

Production OpenMLS Rust & Go Implementations

Production implementation blueprints featuring official IETF RFC 9420 libraries: OpenMLS (Rust) and Go MLS with Delivery Service integration.

MLS (Messaging Layer Security, RFC 9420) & TreeKEM Architecture Studio

Interactive TreeKEM Binary Ratchet Tree Visualizer

MLS Key Schedule & Epoch Secret Derivation Pipeline

MLS Framing, Proposals, Commits & Welcome Wire Anatomy

Protocol Architecture Comparison: MLS vs Signal vs Matrix Megolm

Production OpenMLS Rust & Go Implementations

🔍 Companion Workbenches & Verification Tools

Post-Quantum Signatures: Falcon (NTRU) & SPHINCS+ (SLH-DSA) Studio

WebAuthn LargeBlob & PRF Extension Studio | Hardware Passkey Key Derivation

Schnorr Adaptor Signatures Studio | Scriptless Scripts & Atomic Swaps

CAEP & Shared Signals Protocol Studio: Real-Time Zero Trust Security Events

Why Smart Users Are Switching to This Free Toolkit

The Browser Feature Most People Never Use

Stop Paying for Software You Can Get Free

File Conversion Tricks That Save Hours Every Week

This Free Tool Replaced 5 Paid Apps for Our Team

What Your Browser Can Do Without Any Extensions