Video Call E2EE: SFU Media Key Ratchet

Call Membership

Media send rate 24 pkt/s

The relay server (SFU) only ever sees encrypted packets — it forwards them without being able to open them.

Group Media Key

epoch 0 · key a1b2c3d4

Key epoch

Participants

Time since last rotation

0.0 s

How it works

In an end-to-end encrypted (E2EE) call, participants' devices encrypt each video/audio frame with a shared group media key before it ever leaves the device. The SFU (Selective Forwarding Unit) in the middle only routes ciphertext between participants — it never holds the key, so it cannot decode a frame even though it controls all the traffic.

The group key is not static. Every time membership changes — someone joins or leaves — the key ratchets forward through a one-way key-derivation function:

K(n+1) = KDF( K(n), epoch = n+1 )   // one-way, e.g. HKDF-SHA256 in real systems

Leave → forward secrecy. Because the KDF cannot run backward, a participant who leaves — even a compromised device — cannot derive K(n+1) and loses access to every frame sent after they left.
Join → post-compromise security. A new key epoch also means a newly joined device only gets K(n) onward, never the keys used for frames sent before it arrived.
Intercept attempt. Because the SFU never receives the key, any attempt by the relay (or an attacker who compromises it) to read a packet fails — it only ever holds ciphertext bytes, shown as the red "denied" flash.

This is the same core model used by production E2EE video products (e.g. Signal, Zoom's E2EE mode, Google Meet client-side encryption): a symmetric ratcheting group key, a semi-trusted relay that only forwards ciphertext, and a rotation on every membership change so leaked keys have the shortest possible useful life.

Encrypted media packet SFU relay (never decrypts) Failed decrypt attempt

⚠ Couldn't load the 3D engineThree.js failed to load from the CDN. Check your connection and reload.