Technical Deep Dive

The Cryptographic Architecture of Zevra

A complete technical breakdown of how Zevra achieves zero-knowledge, end-to-end encrypted real-time communication — SRP-6a, X25519, Ed25519 and AES-256-GCM, wired through a blind relay.

Phase 01

SRP-6a

Phase 02

X25519

Phase 03

Ed25519

Phase 04

AES-256-GCM

Client-Side CryptoBlind RelayForward SecrecyPer-Message IVAuthenticated EncryptionStateless NodesSub-10ms DeliveryZero TelemetryEphemeral KeysSigned Payloads

Data Flow

One Message, Six Stops

Follow a single message from your keystroke to your contact's screen. The relay appears in the middle — and never holds a key.

client

Step 01

Compose

Plaintext exists only in this tab's memory.

AES-256-GCM

Step 02

Encrypt

AES-256-GCM seals it with a fresh IV.

Ed25519

Step 03

Sign

Ed25519 proves who wrote it.

blind

Step 04

Relay

The server routes a blob it cannot open.

WebSocket

Step 05

Forward

Socket.IO pushes it to the peer device.

client

Step 06

Decrypt

Peer verifies the signature, then renders.

Encryption Pipeline

How Zevra Encrypts Every Message

From authentication to delivery, every step is designed to keep your data confidential and authenticated.

Phase 01

SRP-6a Authentication

Sign-in runs the Secure Remote Password protocol, so your password never travels over the network. The client produces a proof (A) and verifier (M1); the server answers with its own (B, M2). Both sides arrive at the same session key while neither reveals the password.

Password never transmitted in plaintext

Resistant to offline dictionary attacks

Mutual authentication between client and server

Per-session salt and ephemeral values

Phase 02

X25519 Key Exchange

Every session mints ephemeral X25519 key pairs. Curve25519 Diffie-Hellman establishes a shared secret with no prior contact required — an observer holding the full transcript still cannot derive it without solving the elliptic-curve discrete logarithm problem.

Elliptic Curve Diffie-Hellman (ECDH)

128-bit security level

Ephemeral keys per session (forward secrecy)

Constant-time implementation, timing-attack resistant

Phase 03

Ed25519 Digital Signatures

Key exchanges and payloads are signed with Ed25519, so you can prove a message genuinely came from your contact and was not altered in transit. Signatures are fast enough to verify on every message without perceptible latency.

EdDSA signatures for message authenticity

Tamper-proof delivery — any mutation fails verification

Non-repudiation: sender cannot deny their message

Compact 64-byte signatures

Phase 04

AES-256-GCM Encryption

Message content is sealed with AES-256-GCM, which gives confidentiality and integrity in a single pass. Every message carries a fresh random IV and a 128-bit auth tag, so any modification is detected and rejected before rendering.

256-bit key size — brute force is infeasible

Authenticated encryption (confidentiality + integrity)

Random IV per message prevents pattern analysis

Hardware-accelerated AES-NI where available

Key Management

One Primitive Per Layer

Nothing custom where a published RFC already exists — every layer maps to a single, audited algorithm.

Layer	Algorithm	Purpose
Authentication	SRP-6aRFC 5054 · 2048-bit MODP	Password-based auth without exposing the password
Key Exchange	X25519Curve25519	Ephemeral Diffie-Hellman session keys
Digital Signature	Ed25519EdDSA	Key integrity and identity proof
Symmetric Encryption	AES-256-GCM128-bit IV · 128-bit tag	Authenticated encryption for messages and files
Key Derivation	PBKDF2100K iterations · SHA-256	Password → key material
Key Wrapping	AES-KWRFC 3394	Protects stored cryptographic keys at rest

Protocol Surface

The Complete API Contract

Seven REST endpoints and eight socket events — the entire surface a client can ever touch.

RESTAxios · token interceptors

POST/api/auth/registerRegister new account
POST/api/auth/loginSRP-6a login (start + finish)
GET/api/auth/meValidate token / get profile
PUT/api/users/meUpdate profile
GET/api/keysFetch encryption keys
POST/api/keys/rotateRotate key version
GET/api/auditSecurity audit log

WebSocketSocket.IO 4

C → Ssend-messageSend encrypted payload
S → Cmessage:newReceive encrypted payload
↔typing:start / stopTyping indicators
C → Scall:initiateStart WebRTC / LiveKit call
↔call:offer / answerSDP exchange
↔call:ice-candidateICE candidate exchange
S → Clivekit:token-requestRequest LiveKit SFU token
S → Cheartbeat-ackConnection keepalive

System Topology

Zevra Multi-Node Architecture


    ┌──────────────┐     ┌──────────────┐     ┌──────────────┐
    │   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.

Infrastructure

Real-Time Delivery at Scale

Built for millions of concurrent encrypted sessions with sub-10ms fan-out.

Redis Pub/Sub

Each connected client subscribes to a personal channel. Messages fan out in microseconds with at-most-once semantics, so nothing is duplicated and nothing stalls behind a polling loop.

BullMQ Workers

Redis-backed queues handle delivery retries, push fan-out and priority scheduling, with rate limits and exponential backoff baked into the workers themselves.

Multi-Node Scaling

Stateless nodes sit behind a load balancer with session state in Redis, so any node can answer any request. Scaling out is horizontal and boring — exactly how infrastructure should be.

Zero-Knowledge Server

Nodes store blobs they structurally cannot decrypt. A complete database dump yields ciphertext and hashed identifiers only — server compromise does not equal data compromise.

Platform Matrix

Zevra vs Other Encrypted Chat Platforms

Feature	Zevra	WhatsApp	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

See the Architecture in Action

Every message you send is sealed by the pipeline above before it ever touches the network.