Version 1.1 — July 1, 2026
1. Overview
White Dot is a zero-knowledge messaging platform. This document describes the cryptographic architecture, threat model, and security design of the White Dot protocol. Our goal is to provide private, authenticated, and forward-secure communication with minimal metadata exposure.
2. Threat Model
White Dot's security design defends against the following adversary models:
- Passive network adversary: Can observe all network traffic between client and server.
- Active network adversary: Can intercept, modify, delay, or drop network traffic; can perform man-in-the-middle attacks.
- Server compromise: Full compromise of White Dot's servers; attacker has access to all stored data and infrastructure.
- Device theft: Physical access to a user's unlocked device.
- Legal compulsion: White Dot is legally compelled to hand over user data.
The following are explicitly out of scope:
- Compromise of the recipient's device
- Side-channel attacks on the device hardware
- Defeats of the device secure enclave by the OS vendor
- Quantum cryptanalysis (post-quantum upgrade is planned)
3. Cryptographic Primitives
| Function | Algorithm | Standard |
|---|---|---|
| Key exchange | X25519 | RFC 7748 |
| Message encryption | AES-256-GCM | NIST SP 800-38D |
| Message authentication | HMAC-SHA256 | RFC 4868 |
| Hashing | SHA-256 / BLAKE2b | FIPS 180-4 |
| Digital signatures | Ed25519 | RFC 8032 |
| Key derivation | HKDF | RFC 5869 |
| Random number generation | /dev/urandom / SecureRandom | — |
| Transport security | TLS 1.3 | RFC 8446 |
All cryptographic operations are performed using platform-provided secure implementations (Apple CryptoKit, Android Conscrypt, or BoringSSL). We do not implement cryptographic primitives from scratch.
4. Key Derivation and Management
4.1 Identity Key
Each device generates a long-term Ed25519 key pair at registration. The public key — the Identity Key — is used to establish authenticated channels. The private key never leaves the device's secure enclave. It is used only for signing and DH key agreements.
4.2 Signed Pre-Key
Each device generates a medium-term X25519 key pair — the Signed Pre-Key — signed by the Identity Key. Signed Pre-Keys are rotated every 7 days. The public Signed Pre-Key is uploaded to the server alongside the signature.
4.3 One-Time Pre-Keys
Each device generates a pool of X25519 one-time pre-keys (100 at a time). These are uploaded to the server and consumed during session establishment. When a one-time pre-key is used by an initiating party, the server deletes it. The client replenishes the pool when it falls below 20.
5. Session Establishment
White Dot uses a triple Diffie-Hellman (X3DH) key agreement protocol, inspired by the Signal Protocol:
- Alice fetches Bob's Identity Key, Signed Pre-Key, and a One-Time Pre-Key from the server.
- Alice performs three DH exchanges: (IKA, SPKB), (EKA, IKB), (EKA, SPKB), and optionally (EKA, OPKB).
- The shared secret is derived by concatenating the DH outputs and passing through HKDF.
- Alice sends an initial message containing her Identity Key, Ephemeral Key, and the encrypted first payload.
- Bob performs the corresponding DH calculations and derives the same shared secret.
The resulting shared secret seeds the Double Ratchet protocol for ongoing communication.
6. Double Ratchet Protocol
Each message session uses the Double Ratchet algorithm for continuous key rotation:
- Symmetric ratchet: Derives new message keys from a chain key using HKDF after each message.
- DH ratchet: Each party generates a new ephemeral X25519 key pair periodically (every sent message, if the other party's ratchet has advanced).
- Associated data: Each message includes the public keys of both parties as associated data in the AEAD encryption.
This provides Perfect Forward Secrecy: compromising a session key reveals only that single message, not past or future messages.
7. Message Encryption
Each message is encrypted using AES-256-GCM with a per-message key derived from the Double Ratchet chain. The encryption includes:
- Payload: The message content (text, media metadata, or control message).
- Associated data: Public Identity Keys of both parties, message counter, and protocol version.
- Nonce: A 12-byte nonce derived from the message number.
The server receives only ciphertext, the sender's Identity Key, and protocol metadata (timestamp, message ID). It has no access to plaintext.
8. Media Encryption
Media files (photos, videos, documents) are encrypted before upload using a unique AES-256-GCM key generated per file. The encryption key is transmitted alongside the message through the E2EE channel. The server stores only encrypted blobs and has no access to the decryption key.
9. Push Notification Encryption
Push notification payloads are encrypted using a device-specific key derived from the device's identity key. Push notification services (APNs, FCM) receive only encrypted ciphertext that cannot be decrypted by Apple, Google, or any intermediary.
10. Transport Security
All client-server communication occurs over TLS 1.3 with certificate pinning. The pinned certificate fingerprints are embedded in the application binary and verified on every connection.
11. Server Architecture
The server is designed to be zero-knowledge:
- Stores only encrypted message blobs and public key material
- Has no access to encryption keys
- Can never decrypt messages or media
- Cannot determine conversation participants from stored data
- Implements strict access controls and audit logging
12. Future Roadmap
- Post-quantum cryptographic key agreement (Kyber)
- Sealed sender (server does not learn who is messaging whom)
- Private contact discovery using Intel SGX
- End-to-end encrypted group calls with SFU
13. Contact
For questions about this whitepaper:
Email: crypto@whitedot.chat