Skip to Content
Architecture

Architecture

Technical overview of the Zentalk system architecture.

System Components

Zentalk consists of four core components:

ComponentLanguagePurpose
zentalk-webTypeScript/ReactClient application, local encryption, key management
zentalk-apiGoUser registration, key distribution, message queuing
zentalk-nodeGoRelay network, 3-hop relay routing, mesh storage
zentalk-validatorGoNetwork consensus, identity registration

Encryption Layers

Zentalk applies multiple encryption layers to protect messages:

LayerProtocolPurpose
E2EEX3DH + Double RatchetEnd-to-end message encryption
Post-QuantumKyber-768 (ML-KEM)Quantum-resistant key encapsulation
SymmetricAES-256-GCMMessage payload encryption
TransportTLS 1.3Network connection encryption
At-RestAES-256-GCM + PBKDF2Local storage encryption

Cryptographic Primitives

Key Exchange

AlgorithmPurposeKey Size
X25519Elliptic curve Diffie-Hellman32 bytes
Ed25519Digital signatures32/64 bytes (pub/priv)
Kyber-768Post-quantum KEM1184/2400 bytes (pub/priv)

Symmetric Encryption

AlgorithmPurposeParameters
AES-256-GCMMessage encryption256-bit key, 96-bit nonce, 128-bit tag
HKDF-SHA256Key derivationVariable output length
PBKDF2-SHA256Password-based KDF600,000 iterations

Hashing

AlgorithmPurposeOutput
SHA-256General hashing, HKDF256 bits
BLAKE2bFast hashing, fingerprints256 bits

Message Flow

Messages pass through multiple stages:

  1. Sender encrypts using X3DH + Double Ratchet
  2. Optional PQC layer with Kyber-768
  3. AES-256-GCM seal for symmetric encryption
  4. API receives encrypted payload
  5. Relay network routes via 3-hop relay (Guard → Middle → Exit)
  6. Recipient decrypts in reverse order

Key Types

KeyLifetimePurpose
Identity Key (IK)Long-termUser identification, signing
Signed Pre-Key (SPK)Weekly rotationInitial key exchange
One-Time Pre-Key (OPK)Single useForward secrecy for first message
Ephemeral Key (EK)Per sessionSession forward secrecy
Chain Key (CK)Per ratchet stepDerive message keys
Message Key (MK)Single useEncrypt one message

Data Storage

Client-Side

DataStorageEncryption
Private keysIndexedDBAES-256-GCM + device key
Session stateIndexedDBAES-256-GCM
Message cacheIndexedDBPlaintext (already E2EE)
Key backupMesh storageAES-256-GCM + PBKDF2

Server-Side

DataStorageAccess
Public key bundlesPostgreSQLRead by any authenticated user
Encrypted messagesQueueDeleted after delivery
User metadataMinimalAddress, public keys only

Mesh Storage

Decentralized storage for privacy-preserving data:

ModulePurpose
messagesStore-and-forward encrypted messages
mediaChunked media with per-chunk encryption
keysE2EE key bundle distribution
profileEncrypted profile data sync
call-historyPrivate call logs

Replication & Redundancy

ParameterValue
Replication factor3 nodes minimum
Retention period72 hours (configurable)
Chunk size (media)256 KB
Node selectionDHT-based, XOR distance

Zero-Knowledge Guarantees

The server sees only encrypted blobs. Decryption happens client-side.

Data LayerServer Access
Encrypted blobCan store
Encryption keyCannot access
File metadataCannot read
Access patternsMinimized via padding

Security Headers

HeaderValuePurpose
Cross-Origin-Opener-Policysame-originPrevent cross-origin attacks
Cross-Origin-Embedder-PolicycredentiallessEnable SharedArrayBuffer
Content-Security-PolicystrictXSS prevention
Last updated on
Contact DiscoveryWallet-Based Identity