Skip to Content
Group Chat Protocol

Group Chat Protocol

Technical specification of the Sender Keys protocol for efficient group encryption.

Overview

Group chats use Sender Keys protocol instead of pairwise encryption. Each sender generates a unique key that all group members receive via E2EE channels.

Efficiency

ApproachEncryption OperationsKey Exchanges
Pairwise (n members)O(n) per messageO(n²) total
Sender KeysO(1) per messageO(n) per sender

For a group of 100 members, Sender Keys reduces encryption operations from 100 per message to 1.

Sender Key Structure

Each group member generates their own Sender Key:

FieldTypePurpose
Sender ID32 bytesIdentifies key owner
Chain Key32 bytesDerives message keys
Signature KeyEd25519Authenticates messages
Iterationuint32Current chain position

Key Derivation

For each message: MK, CK_new = HKDF(CK, iteration, "ZentalkSenderKey") ciphertext = AES-256-GCM(MK, plaintext) signature = Ed25519.Sign(SK, ciphertext) CK = CK_new iteration++

Key Distribution

Sender Keys are distributed via existing E2EE sessions:

1. Alice creates group, generates her Sender Key (SK_A) 2. Alice sends SK_A to each member via pairwise E2EE: - To Bob: E2EE(Alice→Bob, SK_A) - To Carol: E2EE(Alice→Carol, SK_A) - To Dave: E2EE(Alice→Dave, SK_A) 3. Bob, Carol, Dave each generate their Sender Keys - Bob sends SK_B to Alice, Carol, Dave via E2EE - Carol sends SK_C to Alice, Bob, Dave via E2EE - etc. 4. Each member stores n-1 Sender Keys from other members

Message Flow

StepSenderRecipients
1Encrypt with own Sender Key-
2Sign ciphertext-
3Broadcast to groupReceive ciphertext
4-Verify signature
5-Decrypt with sender’s key

Group Operations

Adding Members

StepActionSecurity
1Existing member sends inviteE2EE channel
2New member receives all Sender KeysVia E2EE from each member
3New member generates own Sender KeyFresh key
4New member distributes keyE2EE to all

Forward Secrecy: New members cannot decrypt past messages (no key backfill).

Removing Members

StepActionPurpose
1Remove member from rosterAccess revocation
2All remaining members rotate keysForward secrecy
3Distribute new keys via E2EEExclude removed member

Rotation: All members must generate new Sender Keys when someone leaves.

Member Rotation Triggers

EventAction Required
Member joinsNew member creates key, receives others
Member leavesAll members rotate keys
Member device compromiseAffected member rotates key
Key usage limit (1000 msgs)Sender rotates key

Group Metadata

Server Visibility

DataServer Sees
Group IDEncrypted identifier
Member listEncrypted, membership hidden
Message contentEncrypted blob
SenderHidden via anonymous routing

Client-Side Storage

DataStorage
Group rosterIndexedDB, encrypted
Sender Keys (received)IndexedDB, encrypted
Own Sender KeyIndexedDB, encrypted
Message historyIndexedDB, ciphertext

Cryptographic Primitives

AlgorithmUsage
X25519Sender Key distribution (via E2EE)
Ed25519Message signatures
AES-256-GCMMessage encryption
HKDF-SHA256Message key derivation

Security Properties

PropertyMechanism
ConfidentialityAES-256-GCM encryption
IntegrityGCM authentication tag
AuthenticityEd25519 signatures
Forward SecrecyChain key ratcheting
Post-CompromiseKey rotation on events

Message Format

┌─────────────────────────────────────────┐ │ Group ID (32 bytes, encrypted) │ ├─────────────────────────────────────────┤ │ Sender Key ID (8 bytes) │ ├─────────────────────────────────────────┤ │ Chain Iteration (4 bytes) │ ├─────────────────────────────────────────┤ │ Nonce (12 bytes) │ ├─────────────────────────────────────────┤ │ Ciphertext (variable) │ ├─────────────────────────────────────────┤ │ Authentication Tag (16 bytes) │ ├─────────────────────────────────────────┤ │ Signature (64 bytes, Ed25519) │ └─────────────────────────────────────────┘

Limits

ParameterValue
Max group size1000 members
Key rotation threshold1000 messages
Max concurrent groupsUnlimited
Message size limit256 KB
Last updated on