QUANTUM-RESILIENT E2E PROTOCOLS
BlackBox is engineered on math, open architecture, and absolute zero-knowledge compliance. We assume the server is fully compromised. Here is the mathematically provable blueprint of how your messages are secured.
The Elite E2EE Message Pipeline
Upon registration, BlackBox generates a classic X25519 Elliptic-Curve keypair alongside a cutting-edge, quantum-safe ML-KEM-768 (Kyber) keypair entirely client-side using Web Crypto and `@noble/post-quantum`. Your raw private keys never touch the network in plaintext. They are encrypted using AES-GCM-256 derived from your local Device Secret using PBKDF2-SHA256 (600,000 iterations) before any sync.
When starting a conversation, your browser executes a hybrid key exchange. It calculates a standard ECDH shared secret over Curve25519 and encapsulate/decapsulate a post-quantum shared secret via Bob's Kyber public key. This delivers robust defense against immediate attacks and future quantum decryption threats (Harvest-Now-Decrypt-Later).
The two secrets are concatenated [ECDH Secret || Kyber Secret] and ingested into HKDF-SHA256 (HMAC-based Key Derivation) to derive a single 256-bit secure key root. The conversation ID acts as the cryptographic domain separation salt.
The conversation initializes the **Double Ratchet State Machine** using the Hybrid ISS as the `rootKey`. This protocol spins up dynamic key chains for both sending and receiving messages.
For every single message sent or received, the symmetric ratchet advances. The current Chain Key is hashed through Web Crypto HKDF to yield the **Message Key** and the next **Chain Key**. If a message arrives out of order, the engine automatically skips and saves the corresponding Message Key to `skippedMessageKeys` (so it can be decrypted when it eventually arrives), and instantly purges it after use to preserve **Forward Secrecy**.
Whenever Bob replies to Alice, your browser performs an asymmetric ratchet rotation. Bob rolls his local X25519 DH keypair, encapsulates it in his outgoing message, and both parties calculate a new `rootKey` and reset the Chain Keys. This guarantees **Post-Compromise Security** — even if an attacker gains access to your active session keys, they will lose access to all future messages as soon as the keys ratchet again.
The derived Message Key is used to encrypt the payload locally. To guarantee flawless, responsive performance and prevent CPU jank during long sessions, all encryption and decryption operations are offloaded into background Web Workers.
The server acts strictly as an untrusted mailman. It receives only: the Encrypted Ciphertext, 12-byte IV, sender/receiver blind hashes, and the current ephemeral DH Public Key needed to ratchet keys. The server possesses no private keys, no device secrets, and no session keys. It is physically, mathematically, and architecturally blind.
Users can configure conversation-wide **Disappearing Messages** set to 24 Hours, 7 Days, or "After-Seen". Time-based constraints are verified during database fetches to prevent stale keys from loading, while "After-Seen" immediately flags read messages as deleted for the sender once the recipient emits a `conversation:read` WebSocket event.
Blocking an account pushes the target user's ObjectId to your `blockedUsers` document array. The Node/TypeScript socket namespace intercepts the `message:send` packet and performs strict database cross-checks to drop unauthorized socket transfers before message serialization.
Executing "Clear Chat" instantly purges E2EE records strictly on the initiator's terminal and server indices by marking them `deletedFor: "sender"`. This ensures immediate local erasure without unilaterally destroying the recipient's secure database logs without their consent.
Cryptographic Algorithms & Protocols
ML-KEM-768 (Kyber) — Post-Quantum KEM
Approved by NIST as the ultimate standard for Post-Quantum Cryptography (PQC). It protects against "Harvest-Now-Decrypt-Later" attacks, where adversaries store encrypted traffic today with the plan to decrypt it when quantum computers become operational.
Double Ratchet Protocol — Dynamic Ephemeral Keys
Combines a cryptographic **KDF Chain Ratchet** (symmetric) and a **DH Ratchet** (asymmetric). By dynamically regenerating new keys for every single message and conversation turn, it delivers:
• Forward Secrecy: If an attacker steals a key today, they cannot decrypt any past messages.
• Post-Compromise Security: If an attacker compromises your active session, they are permanently locked out of all future messages as soon as the key ratchets with the next response.
Zero-Knowledge Blind Indexing — Anonymous Lookups
To contact another user, BlackBox uses **Blind Indexing**. When you register a username or email, your browser hashes the normalized value locally with a fixed salt. The server stores only this SHA-256 hash. When you search for a contact, your browser computes the hash client-side and transmits only the hash. The server looks up the corresponding public keys without ever knowing your actual username, email, or search terms.
Out-of-Band Safety Numbers — Identity Verification
To guarantee you are communicating with the actual recipient (and rule out any active Machine-in-the-Middle spoofing), BlackBox generates a **Safety Number**. This 60-digit numeric fingerprint is derived from a SHA-512 digest of both participants' sorted public identity keys. Users can visually compare this fingerprint side-by-side or scan the dynamically generated canvas QR code out-of-band (e.g., in person or via video call) to mathematically verify the secure channel.
PBKDF2-SHA256 (600,000 iterations) — Key Backup Protection
To back up your private keys so you can restore your chat history, the keys are encrypted using a key derived from your local **Device Secret** (which never leaves your device). The derivation applies PBKDF2 with 600,000 rounds of SHA-256 and a random 16-byte salt, creating absolute resistance against offline brute-force attacks.
AES-GCM-256 — Authenticated Data Encryption
Advanced Encryption Standard in Galois/Counter Mode with 256-bit keys. AES-GCM is an Authenticated Encryption with Associated Data (AEAD) system. It guarantees both absolute message confidentiality and cryptographic tamper detection (if a single bit of ciphertext is altered, decryption will fail completely).
Physical Metadata Isolation
✓ What Is Stored on the Server
- Encrypted message ciphertexts + 12-byte AES-GCM IVs
- Random UUID user and conversation identifiers
- Symmetric ratchet session sequence numbers
- Latest dynamic Double Ratchet public keys (necessary to align handshakes)
- Public Identity Keys (X25519 + ML-KEM-768)
- Encrypted private identity backup payload (AES-GCM-256, mathematically undecryptable by server)
- Client-derived SHA-256 blind index hashes of your username/email
✗ What We Can Never Store or Access
- Plaintext message text, images, or media contents
- Your local Device Secret, account password, or local PBKDF2 seed
- Decrypted Double Ratchet root, sending, or receiving chain keys
- Plaintext usernames, emails, or search lookup queries
- Real-time IP logs, typing indicators, read receipts, or geolocation
⚠ Crucial Operating Guidelines
E2E cryptography protects the pipeline, but security requires strict discipline:
- The Device Secret is your Master Key. If you lose your Device Secret, we cannot recover your backed-up private keys. If you share your Device Secret, your encryption keys can be compromised. Guard it as your highest secret.
- Perform Out-of-Band Safety Checks. Always open the Identity Verification modal in the chat and compare safety numbers fingerprint or scan the QR code with your partner over a trusted voice, video, or in-person channel.
- Hardware Integrity is a Prerequisite. Cryptography is useless if your system contains malware, keyboard monitors, screen capture utilities, or active browser-extension compromises. Secure your device.
- No Read Receipts & No Metadata Trails. We do not log message reads or presence to prevent traffic-analysis correlation. Messages are kept encrypted until explicitly deleted by participants.