End-to-End Encryption Architecture

The Problem with Traditional Chat Apps

Many messaging apps claim end-to-end encryption but still expose message content to third parties. Push notification providers (APNS/FCM) receive plaintext message bodies, and relay servers can see unencrypted content. Even with encryption, these apps often collect metadata - who you talk to, when, for how long, and from where.

Our Approach: True End-to-End Encryption

Vant Chat uses a Telegram-style architecture where the relay server never sees message content. Messages are encrypted on the sender's device using the recipient's public key, and only the recipient can decrypt them. For push notifications, we use silent data-only pings that wake the app to fetch and decrypt messages on-device.

Device A (Encrypt)

→

Relay Server (No Content)

→

Device B (Decrypt)

Key Architectural Principles

X25519 Key Exchange: Each device has a long-lived X25519 keypair. Public keys are exchanged during connection.
AES-256-GCM Encryption: Messages are encrypted with AES-256-GCM using a per-contact derived key.
Silent Push Notifications: FCM/APNS receive only metadata (sender ID, message type), never message content.
Temporary Server Storage: Messages are temporarily stored in encrypted form on our relay server for offline delivery (up to 7 days), then automatically deleted. Contacts and app data are stored exclusively on user devices.
No User Accounts: Without accounts, there's no user data to collect or profile.

Technical Implementation

1. Key Pair Generation

Each device generates a long-lived X25519 keypair on first launch. The private key is stored in the device's hardware-backed secure storage (iOS Keychain / Android Keystore) and never leaves the device.

Device Key Pair Generation

            // Generate X25519 keypair for E2EE const keyPair = await
            X25519.newKeyPair(); const privateKey = await
            keyPair.extractPrivateKeyBytes(); const publicKey = await
            keyPair.extractPublicKey(); // Store private key in hardware-backed
            storage await secureStorage.set('e2ee_private',
            base64Encode(privateKey));
          

2. Message Encryption

When sending a message, the sender derives a shared secret using their private key and the recipient's public key via X25519 ECDH. This secret is then used with HKDF-SHA256 to derive an AES-256-GCM key for message encryption.

Message Encryption

            // Derive shared secret via X25519 const sharedSecret = await
            X25519.sharedSecretKey( keyPair: myKeyPair, remotePublicKey:
            recipientPublicKey ); // Derive AES-256-GCM key via HKDF const
            aesKey = await Hkdf.hmacSha256().deriveKey( secretKey: sharedSecret,
            nonce: [], info: utf8.encode('vant-chat-e2ee-v1') ); // Encrypt
            message with AES-256-GCM const encrypted = await
            AesGcm.with256bits().encrypt( utf8.encode(message), secretKey:
            aesKey, nonce: AesGcm.with256bits().newNonce() );
          

3. Offline Message Handling

When a recipient is offline, messages are stored encrypted in Redis (ElastiCache) with a 7-day TTL. The server never sees plaintext - only the encrypted payload and the sender's public key for key exchange.

Messages are encrypted with the recipient's public key before sending to server
Stored temporarily in Redis with 7-day expiration
Server relays sender's public key with the message for decryption
No plaintext content ever stored on server

Offline Message Storage

            // Server stores encrypted message only await redis.setex(
            `msg:${recipientDeviceId}`, 7 * 24 * 60 * 60, // 7 days
            JSON.stringify({ messageId, senderDeviceId, encryptedPayload, //
            E2EE encrypted senderPublicKey, // For key exchange timestamp }) );
          

Security Benefits

1. Push Notification Privacy

Traditional apps send message content to Google/Apple via FCM/APNS. Vant Chat uses silent data-only pushes that contain only metadata (sender ID, message type). The app wakes up, fetches the encrypted message from the server, decrypts it on-device, and shows a local notification.

2. Server Cannot Read Messages

The relay server sees only encrypted payloads and public keys. Without private keys, the server cannot decrypt any message content, even if compelled to do so.

3. Forward Secrecy

Each message uses a unique nonce for AES-256-GCM encryption. Compromise of a long-term key does not reveal past messages. Future key rotation can provide additional forward secrecy guarantees.

Voice Call Encryption

1. WebRTC Peer-to-Peer Audio

Voice calls use WebRTC for peer-to-peer audio streaming. Media flows directly between devices whenever possible, minimizing server involvement. The relay server only handles signaling (call setup, ICE candidate exchange) and never sees or processes audio data.

2. Call Key Derivation

Call encryption keys are derived using HMAC-SHA256 keyed by each device's hardware-backed master key. Both callers arrive at the same key because device IDs are sorted before hashing. This ensures that even if someone knows the device IDs, they cannot derive the call key without access to the physical device's secure storage.

Call Key Derivation

            // Get hardware-backed master key const masterKey = await
            secureKeyService.requireMasterKey(); // Sort device IDs so both
            parties compute same input const sortedIds = [deviceId1,
            deviceId2].sort(); const message =
            utf8.encode(`${sortedIds[0]}_${sortedIds[1]}`); // HMAC-SHA256: key
            = device master key, message = sorted device IDs const hmac =
            Hmac.sha256(); const secretKey = SecretKey(masterKey); const mac =
            await hmac.calculateMac(message, secretKey: secretKey); // Clear
            master key from memory immediately masterKey.fillRange(0,
            masterKey.length, 0); // Use 256-bit MAC as call encryption key
            const callKey = base64Encode(mac.bytes);
          

3. Security Benefits

Hardware-Backed Keys: Master keys are stored in iOS Keychain / Android Keystore and never leave the device.
Peer-to-Peer Media: Audio flows directly between devices, minimizing server exposure.
Deterministic Key Derivation: Both parties derive the same key without additional key exchange.
No Server Recording: The relay server never sees or stores call audio.

Performance Optimizations

1. Smart Relay Selection

We use machine learning to select optimal relay nodes based on:

Network latency
Node reliability
Geographic proximity
Current load

2. Message Batching

Multiple small messages are batched together to reduce overhead and improve delivery speed.

Message Batching

            class MessageBatcher { constructor(batchSize = 10, flushInterval =
            100) { this.messages = []; this.batchSize = batchSize;
            this.flushInterval = flushInterval; } addMessage(message) {
            this.messages.push(message); if (this.messages.length >=
            this.batchSize) { this.flush(); } } flush() { if
            (this.messages.length > 0) { const batch = this.messages.splice(0);
            this.sendBatch(batch); } } }
          

The Future of Private Communication

This relay-based architecture with end-to-end encryption represents a privacy-focused approach to digital communication. By making message content technically inaccessible to the server through E2EE, we're creating a higher standard for secure messaging.

As governments worldwide increase surveillance demands and tech companies continue to exploit user data, architectures like Vant Chat's become not just preferable, but necessary for preserving fundamental human rights to privacy and free expression.

Join the Privacy Revolution

Experience messaging the way it should be - private, secure, and with reduced surveillance risk through end-to-end encryption.

Download Vant Chat Now

Technical Resources

For developers interested in learning more about our architecture: