RFC 9420 • MLS Standard

How We Keep It Secret.

Understanding the cryptographic machinery behind MicroChat, from simple analogies to deep protocol mechanics.

In Progress
Protocol
MLS
RFC 9420 Standard
Live
Topology
TreeKEM
Logarithmic Efficiency
In Progress
Primitives
HPKE
Hybrid Public Key Enc.
The Architecture

TreeKEM & Continuous Group Key Agreement

MicroChat implements Messaging Layer Security (MLS), which solves the scalability issues of pairwise encryption (Signal Protocol) in large groups.

Instead of encrypting a message N times for N recipients, MLS arranges members in a left-balanced binary tree (Ratchet Tree). Each node in the tree represents a public/private key pair.

  • 1.Leaf Nodes: Represent individual members.
  • 2.Path Secrets: Members know all private keys on their direct path to the root.
  • 3.Root Key: The shared group secret used to derive message encryption keys.

When a member updates their key (Post-Compromise Security), they generate a new path secret and encrypt it up the tree. This achieves O(log N) efficiency for group operations.

Ratchet tree at rest — all members hold root key
E1
Root
A
B
U1
U2
U3
U4

Epochs & Erasure

The state of the group advances in discrete Epochs. Each Commit (add, remove, or key update) transitions the group to Epoch N+1. Application messages do not advance the epoch.

Forward Secrecy

Key material for Epoch N is derived from Epoch N-1 via a one-way KDF chain. Once Epoch N-1 is deleted, its keys cannot be re-derived, ensuring past messages remain secure even if current state is compromised.

Post-Compromise Security

If an attacker compromises a device, they can be healed out of the group. As soon as the compromised member (or any other member) sends a Key Update, the new entropy restores the group's security, locking out the attacker from future messages.

Anonymity

Sealed Sender Routing

MicroChat implements Sealed Sender to decouple message routing from sender identity. Network metadata is often as sensitive as the message contents.

Our implementation issues cryptographic blinding tokens to clients representing "the right to send one message".

  • 1.Token Issuance: Clients fetch batches of 32-byte secure random tokens.
  • 2.Server Blindness: The server only stores the SHA-256 hash of tokens. It cannot link a token back to the requesting user.
  • 3.Anonymous Delivery: Messages are sent with sender_id = NULL and a valid plaintext token.

The true sender identity is embedded inside the AES-GCM encrypted payload, accessible only by group members with the current epoch key.

Sealed sender — identity decoupled from routing
Client
Server
Group
token