From authentication to delivery, every step in Zevra's pipeline is designed to keep your data confidential and authenticated.
When you sign in to Zevra, the Secure Remote Password protocol ensures your password never travels over the network. The client generates a proof (A) and verifier (M1) while the server responds with its own proof (B, M2). Both sides derive the same session key without either revealing the password.
Every Zevra chat session generates ephemeral X25519 key pairs. The Curve25519 Diffie-Hellman protocol establishes a shared secret between two parties without any prior contact. Even if an attacker intercepts all traffic, they cannot derive the shared secret without solving the elliptic curve discrete logarithm problem.
Every message and key exchange in Zevra chat is signed with Ed25519 keys. This ensures authenticity: you can verify that a message genuinely came from your contact and was not tampered with in transit. The signature is fast to generate and verify, adding negligible overhead to real-time communication.
The actual message content is encrypted with AES-256-GCM, the gold standard for symmetric encryption. GCM mode provides both confidentiality and integrity: each message is encrypted and authenticated, meaning any modification is detected and rejected. Your plaintext never exists on Zevra's servers.
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Client A │ │ Client B │ │ Client C │
│ (Browser) │ │ (Browser) │ │ (Browser) │
└──────┬───────┘ └──────┬───────┘ └──────┬───────┘
│ X25519/AES-256 │ X25519/AES-256 │ X25519/AES-256
│ │ │
───────┼────────────────────┼────────────────────┼───────
│ │ │
┌──────▼────────────────────▼────────────────────▼───────┐
│ Load Balancer │
└──────┬────────────────────┬────────────────────┬───────┘
│ │ │
┌──────▼───────┐ ┌──────▼───────┐ ┌──────▼───────┐
│ Node 1 │ │ Node 2 │ │ Node 3 │
│ (Stateless) │ │ (Stateless) │ │ (Stateless) │
└──────┬───────┘ └──────┬───────┘ └──────┬───────┘
│ │ │
───────┼────────────────────┼────────────────────┼───────
│ │ │
┌──────▼────────────────────▼────────────────────▼───────┐
│ Redis (Pub/Sub + BullMQ) │
│ Message Queues + Session State │
└────────────────────────────────────────────────────────┘
Every message is encrypted client-side before transmission. Zevra servers process only ciphertext.
Zevra's backend is built for millions of concurrent encrypted chat sessions with sub-10ms delivery.
Real-time message routing through Redis channels. Each connected client subscribes to their personal channel. Messages are delivered in microseconds with at-most-once delivery semantics, ensuring no duplicates in your Zevra chat.
Background job processing for message queuing, delivery retries, and push notifications. BullMQ provides reliable, Redis-backed job queues with rate limiting, retries, and priority scheduling for Zevra's multi-node architecture.
Zevra's backend runs as a cluster of stateless nodes behind a load balancer. Session state lives in Redis, allowing any node to handle any request. This architecture enables horizontal scaling to millions of concurrent encrypted chat sessions.
Zevra's servers are designed to be zero-knowledge by construction. They store only encrypted blobs they cannot decrypt. Even database dumps yield nothing but ciphertext. Server compromise does not equal data compromise.
| Feature | Zevra | Signal | |
|---|---|---|---|
| Password Transmitted | Never | Hashed | Never |
| Key Storage | Client-side only | Server backup | Client + optional backup |
| Encryption Protocol | AES-256-GCM + X25519 | Signal Protocol | Signal Protocol |
| Authentication | SRP-6a | Phone number | Phone number |
| Open Source | Fully auditable | Partial | Fully auditable |
| Video Conferencing | E2EE | E2EE | E2EE |
| Zero-Knowledge Server | Yes | No | No |