Security

The crypto stack, documented

Every algorithm we use, why we chose it, and what the server can and cannot see. No vague assurances — specific claims you can verify.

Cryptographic Algorithms

ML-KEM-768

FIPS 203 Key Encapsulation

Module Lattice Key Encapsulation Mechanism. Used for quantum-resistant key exchange during session establishment. Security based on the hardness of Module Learning With Errors (MLWE). Composed with X25519 in a hybrid construction for defense-in-depth.

ML-DSA-65

FIPS 204 Digital Signatures

Module Lattice Digital Signature Algorithm. Used for authenticating identity keys and signing ephemeral KEM public keys. Provides authentication and non-repudiation. Enables safety number verification.

AES-256-GCM

FIPS 197 Authenticated Encryption

Advanced Encryption Standard in Galois/Counter Mode. Used for symmetric authenticated encryption of message payloads and call frames. Provides both confidentiality and integrity — modifications to ciphertext are detected.

HKDF-SHA-256

RFC 5869 Key Derivation

HMAC-based Key Derivation Function. Combines the ML-KEM-768 and X25519 shared secrets with identity key material to derive session keys. Ensures that derived keys are properly bound to both parties.

PQ Double Ratchet

Extended Signal Protocol Forward Secrecy

The Double Ratchet algorithm extended with KEM-based ratchet steps using ML-KEM-768. Provides forward secrecy (compromise of a current key cannot reveal past messages) and break-in recovery (future messages become secure again after a KEM ratchet step).

Threat Model: Harvest Now, Decrypt Later

The primary threat SpeakEasy is designed to counter is the "harvest now, decrypt later" (HNDL) attack. Adversaries with network access record encrypted traffic today. Classical encryption (ECDH, RSA) is vulnerable to Shor's algorithm on a quantum computer. When a cryptographically relevant quantum computer exists, stored ciphertext can be decrypted retroactively.

By replacing classical key exchange with ML-KEM-768, ciphertext recorded today remains secure even against a future quantum adversary — provided the post-quantum algorithm is not broken.

Secondary threats addressed include real-time interception, server compromise, and client device compromise. The PQ Double Ratchet limits the damage from key compromise: a compromised session key exposes only messages encrypted under that specific ratchet state.

Server Visibility

What the server CAN see

  • Your IP address
  • Connection timestamps
  • Socket events (connect, disconnect)
  • Encrypted packet sizes
  • Session token (opaque, not linked to identity)

What the server CANNOT see

  • Message content
  • Call audio or video
  • Your identity keys
  • Who you are communicating with (blind relay)
  • Your contact list
  • Message metadata beyond packet sizes

Blind relay: The server routes packets by session token, not by user identity. The session token is generated ephemerally and not linked to your account in the relay log. The server does not learn the IP addresses of both parties in a call — each client connects to the relay independently.

Safety Numbers and Identity Verification

SpeakEasy uses a Trust On First Use (TOFU) model. When you first contact someone, their identity key (ML-DSA-65 public key) is recorded and pinned. Subsequent connections are verified against the pinned key.

Safety numbers are a human-readable fingerprint derived from both parties' identity keys. To verify that no one is in the middle of your communication, both parties compare their safety numbers out-of-band — in person, by phone, or via another trusted channel. If the numbers match, the session is authenticated.

If a contact's identity key changes (for example, they reinstalled the app on a new device), SpeakEasy displays a warning. In Standard mode, this is an informational alert. In Hardened mode, communication is blocked until you explicitly re-verify.

Hardened Mode

Hardened mode is designed for users with elevated threat models: journalists communicating with sources, activists in authoritarian contexts, security researchers, legal professionals, and others for whom metadata or key compromise could have serious consequences.

  • Safety numbers must be verified manually before any call is permitted
  • Strict key pinning — any key change immediately blocks the contact and requires re-verification
  • Contact list is never transmitted to the server in any form
  • New device pairings require explicit confirmation with safety number re-verification
  • No automatic key refresh without user acknowledgment
  • Sealed sender — recipient cannot determine your network identity from packet metadata
  • Audit log — all key events, verifications, and warnings are recorded locally on device

Data Retention

Connection metadata is retained for a limited period and then permanently deleted. We do not retain call recordings, message content, or any decrypted data — we do not have access to any of it.

You can delete your account at any time from the app settings. Account deletion is permanent and immediate.