Semafore Docs
Back to semafore.io

Security Architecture

Overview

Core Guarantee

SemaFore implements end-to-end encryption such that plaintext message content is encrypted on the sender’s device before transmission. The server receives and routes ciphertext only. SemaFore (Attomus, the operator) has no cryptographic mechanism—and no key material—with which to decrypt message content. The server routes ciphertext to intended recipients; decryption occurs on the recipient device only, under control of the recipient’s private keys.

Cryptographic Foundation: Signal Protocol

SemaFore uses the Signal Protocol, the same protocol deployed in Signal Messenger and WhatsApp. The protocol consists of two components:

  1. X3DH (Extended Triple Diffie-Hellman): Establishes a shared secret between sender and recipient when they first exchange messages. The protocol uses four Diffie-Hellman operations to bind the long-term identity of each participant to the shared secret, preventing man-in-the-middle attacks even if an intermediate key is later compromised.

  2. Double Ratchet: Advances the encryption key for each message using a combination of symmetric ratcheting (each message gets a unique key derived from the previous one) and Diffie-Hellman ratcheting (periodic re-keying with fresh ephemeral key pairs). This design provides forward secrecy: if a session key is compromised at time T, messages sent before T remain encrypted.

What the Server Holds

The server stores:

  • Ciphertext: the encrypted message payload, encrypted under keys the server never possesses
  • Public key material: one per device, organized into “key bundles” consisting of:
    • Identity Key (IK): a long-term Curve25519 public key that serves as the cryptographic anchor for the device
    • Signed Pre-Key (SPK): a medium-term Curve25519 public key signed by the Identity Key, used in session establishment and rotated periodically
    • One-Time Pre-Keys (OPKs): ephemeral Curve25519 public keys, consumed one per new session, replenished when supply runs low
  • Device tokens: phone numbers, push notification endpoints, device registrations — metadata necessary for routing
  • Audit metadata: who sent what to whom, when, message identifiers, and recipient counts — but never the message content itself

What the Server Cannot Hold

The server does not:

  • Hold plaintext message content at any point
  • Possess private keys (Identity Key, Signed Pre-Key, or One-Time Pre-Key) for any device
  • Hold session keys or message decryption keys
  • Decrypt past or future messages, even if a device goes offline and comes online later

Key Types and Roles

Each device generates and manages three key types:

  • Identity Key (IK): generated once at device registration, never leaves the device, serves as the long-term cryptographic anchor
  • Signed Pre-Key (SPK): a medium-term key signed by the Identity Key, used in X3DH session establishment, rotated on a schedule (default: every 7 days)
  • One-Time Pre-Keys (OPKs): ephemeral keys consumed one at a time when recipients establish new sessions, replenished automatically when supply falls below a threshold (default: 5)

The details of each key type, the session establishment protocol, message encryption, and key rotation are covered in the pages that follow: