Skip to main content

> ENCRYPTION_PROTOCOL

Technical deep dive into how Phantom Chat protects your messages

> OVERVIEW

Phantom Chat implements true end-to-end encryption using modern Web Crypto APIs. This means your messages are encrypted in your browser before being sent, and can only be decrypted by the intended recipient.

Encryption:AES-256-GCM
Key Exchange:ECDH (P-256 curve)
Key Derivation:HKDF-SHA256
IV Generation:96-bit random per message

> ECDH_KEY_EXCHANGE

Elliptic Curve Diffie-Hellman (ECDH) allows two parties to establish a shared secret over an insecure channel without ever transmitting the secret itself.

The Process:

  1. Key Generation: Each user generates an ECDH key pair (public + private) using the P-256 curve. This happens locally in the browser.
    crypto.subtle.generateKey({name: "ECDH", namedCurve: "P-256"})
  2. Public Key Exchange: Users exchange their public keys through the Phantom Chat server. The server only sees public keys (useless without the private counterpart).
  3. Shared Secret Derivation: Each browser combines its private key with the other user's public key to compute an identical shared secret.
    crypto.subtle.deriveBits({name: "ECDH", public: otherKey}, myPrivateKey, 256)
  4. Key Derivation: The shared secret is passed through HKDF to derive the final AES-256 encryption key.

[NOTE] The mathematical properties of ECDH ensure that even if an attacker intercepts both public keys, they cannot compute the shared secret without one of the private keys.

> AES_256_GCM_ENCRYPTION

AES-256-GCM (Galois/Counter Mode) is a symmetric encryption algorithm that provides both confidentiality and integrity. The "256" refers to the key size in bits.

ENCRYPTION

Each message is encrypted with a unique 96-bit Initialization Vector (IV). This ensures identical messages produce different ciphertexts.

AUTHENTICATION

GCM mode generates an authentication tag that detects any tampering. Modified messages are rejected during decryption.

Message format:

[IV (12 bytes)] + [Ciphertext] + [Auth Tag (16 bytes)]

> ENCRYPTION_FLOW

1. USER_A sends message:

→ Generate random 96-bit IV

→ Encrypt plaintext with AES-256-GCM

→ Concatenate IV + ciphertext + tag

→ Base64 encode for transport

→ Send to server

2. SERVER relays:

→ Receives encrypted blob

→ Cannot decrypt (no key)

→ Stores temporarily

→ Forwards to USER_B

3. USER_B receives:

→ Base64 decode

→ Extract IV from first 12 bytes

→ Decrypt with shared AES key

→ Verify authentication tag

→ Display plaintext

> SECURITY_GUARANTEES

CONFIDENTIALITY

Only parties with the shared key can read messages. 256-bit keys are computationally impossible to brute force.

INTEGRITY

GCM authentication tags detect any modification to the ciphertext. Tampered messages fail decryption.

FORWARD SECRECY

Each room generates new keys. Compromising one room doesn't affect past or future conversations.

ZERO KNOWLEDGE

Servers never see plaintext or encryption keys. We mathematically cannot access your messages.

SEE IT IN ACTION

Experience military-grade encryption firsthand

[CREATE_SECURE_ROOM][SECURITY_OVERVIEW]