/ MLS PROTOCOL · INTERACTIVE

See how a group key actually rotates.

MLS (Messaging Layer Security, RFC 9420) is the IETF protocol Koaich uses for encrypted group rooms. The mechanics are easier to feel than to read about. Add members. Send a message. Remove a member. Send another message. See why the departed member can't read it, and why the server can't either.

This is a visualization, not a real MLS implementation — the "keys" here are pseudo-random for clarity. For the protocol's actual cryptography see RFC 9420 or our explainer at /learn/mls-workspace-privacy.

EPOCH 2

group key: 6b8c2cc6945c13df

2 / 8 ACTIVE

Each leaf is a group member. Internal nodes hold derived keys; the root is the current group key. Every membership change recomputes the keys on the path from the affected leaf to the root, which advances the epoch and locks departed members out of future messages.

MEMBERSHIP

AliceJOINED EP 1

BobJOINED EP 2

SEND A MESSAGE

VIEWING AS

No messages yet. Send one from a member above to see how each viewer perceives it.

OPERATION LOG (newest at bottom)

step 0 · ep 0Empty group at epoch 0 — no members yet.

step 1 · ep 1Alice joined the group. Tree rebalanced; group key rotated to epoch 1.

step 2 · ep 2Bob joined the group. Tree rebalanced; group key rotated to epoch 2.

Try these scenarios

1. Forward secrecy on member churn

Add three members (Alice, Bob, Carol). Send a message as Alice. Switch the viewer to Bob — he can read it. Remove Bob. Send another message as Alice. Switch viewer back to Bob: he can't read the new message. That's the cryptographic property — Bob's device no longer has the epoch key the message was sealed under.

2. Backward security on join

Send a message as Alice early. Then add a new member, Dan. Switch the viewer to Dan and look at the early message: he sees ciphertext. The epoch key for that message existed before Dan joined; his device never received it. This is what prevents a new admin from reading historical confidential threads.

3. The server-blind property

At any time, switch the viewer to Koaich server (what we hold). Every message is ciphertext. The server sees the sender id, the epoch number, and the timestamp — never the content. Every operation in the log is something the server can observe; the content of messages is something the server cannot.

4. Forward secrecy without churn

Click Re-key (no churn). The group key rotates to a new epoch with no membership change. A future device compromise that recovers an old epoch key can't decrypt messages from later epochs. Real MLS does this automatically on every message via key ratcheting; this button lets you trigger it manually.

What this simulation simplifies

· No real cryptography. The "group key" is a deterministic pseudo-random string for clarity. Real MLS uses HKDF-SHA-256 (or a configurable hash) to derive keys from a tree of secrets; the ciphertext is real AEAD (typically AES-128-GCM or ChaCha20-Poly1305).
· Tree size is fixed at 8 leaves. Real MLS scales to thousands of members; the tree resizes as needed.
· No re-keying on every message. Real MLS advances the key ratchet on every message. The playground only advances on membership change + manual re-key, to keep the visualization legible.
· No external trust roots. Real MLS uses signature keys + credential verification to prove identity. The playground assumes every named member is who they claim to be.
· No partial-trust handling. Real MLS lets members agree on the current tree via Commit messages with signatures; this playground updates state instantly.

Built on the protocol you just played with.

Koaich uses real MLS (RFC 9420) for every group room. Get on the waitlist.