Abstract
MicroChat is a group messaging service built on the Messaging Layer Security (MLS) protocol [RFC 9420]. This document describes the cryptographic architecture, key management lifecycle, and threat model that underpin its security guarantees.
The primary security properties are: end-to-end confidentiality, forward secrecy, and post-compromise security. Messages are encrypted on-device before transmission; the server processes only opaque ciphertext and never holds key material.
Introduction
Existing messaging protocols either target one-to-one communication (Signal Protocol) or sacrifice security for scalability (server-side fanout). MLS addresses this gap by providing an authenticated group key agreement protocol that scales to large groups while preserving strong security guarantees.
MicroChat adopts MLS as its core protocol and augments it with a lightweight Sealed Sender scheme to reduce server-visible metadata. This document is intended for security researchers, auditors, and engineers evaluating the system.
Cryptographic Primitives
| Primitive | Algorithm | Status |
|---|---|---|
| Key Agreement | P-256 (ECDH) | Live |
| Symmetric Encryption | AES-256-GCM | Live |
| Key Derivation | HKDF-SHA-256 | Live |
| Digital Signatures | Ed25519 | Pending |
| Public Key Encryption | HPKE (X25519, AES-GCM) | Pending |
| Hash | SHA-256 | Live |
Key derivation follows the HKDF construction [RFC 5869] throughout. The Web Crypto API is used for all cryptographic operations in the browser client to ensure hardware acceleration and avoid side-channel vulnerabilities in JavaScript.
Protocol Design
3.1 TreeKEM & Ratchet Tree
MLS arranges group members as leaves of a left-balanced binary tree. Each interior node holds a derived key pair. A member's path secret is the sequence of private keys along its direct path to the root.
Group key material (the epoch secret) is derived from the root node's key using HKDF. All per-message keys are derived from the epoch secret, ensuring that different epochs produce cryptographically independent key streams.
[Diagram: ratchet tree with 4 members — pending]
3.2 Commits & Proposals
Group state advances through Commits. A Commit bundles one or more Proposals (Add, Remove, Update) and transitions the group to a new epoch. Each Commit is authenticated with the committer's leaf credential.
Application messages do not advance the epoch. This means a sender's burst of messages all encrypt under the same epoch key, with per-message nonces derived via a symmetric ratchet.
3.3 Sealed Sender
PartialTo reduce server-visible metadata, MicroChat issues single-use blinding tokens to clients. When sending a message, a client presents a token in lieu of an authenticated identity. The server verifies the token's hash but cannot link it to the requesting account.
The true sender identity is included inside the MLS ApplicationMessage ciphertext, visible only to group members with the current epoch key.
Key Lifecycle
Keys are generated client-side using crypto.subtle.generateKey and are never transmitted to the server in plaintext. Leaf key packages (used for initial group add operations) are uploaded in encrypted form and rotated after each use.
On group deletion, the server deletes all stored ciphertext. Because no plaintext key material ever resided on the server, the stored blobs become permanently irrecoverable.
Threat Model
| Threat | Mitigated | Notes |
|---|---|---|
| Passive network observer | Yes | All traffic is TLS + E2E encrypted |
| Compromised server | Yes | Server holds only opaque ciphertext |
| Malicious insider | Yes | No plaintext key material server-side |
| Stolen long-term keys | Yes | Forward secrecy via epoch rotation |
| Compromised device | No | Out of scope — endpoint security |
| Global passive adversary | No | Traffic analysis not addressed |
MicroChat does not protect against a fully compromised client device, coercive key extraction, or traffic analysis by a global passive adversary. These are out of scope and documented in the full threat model.
Limitations & Future Work
- —Metadata minimization beyond Sealed Sender (e.g., Private Information Retrieval for message fetch)
- —Formal verification of the key schedule using ProVerif or Tamarin
- —Hardware security key (WebAuthn) integration for leaf credential binding
- —Multi-device support and key consistency across sessions
References
- 1.[RFC 9420] Barnes, R. et al. "The Messaging Layer Security (MLS) Protocol." IETF, 2023.
- 2.[RFC 5869] Krawczyk, H. and P. Eronen. "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)." IETF, 2010.
- 3.[HPKE] Barns, R. et al. "Hybrid Public Key Encryption." RFC 9180, IETF, 2022.
- 4.[TreeKEM] Bhargavan, K. et al. "TreeKEM: Asynchronous Decentralized Key Management for Large Dynamic Groups." RWC 2019.
- 5.[Signal] Marlinspike, M. and Perrin, T. "The Double Ratchet Algorithm." Signal, 2016.