SemaFore Docs
Back to semafore.io

Security Architecture

Overview

Last updated: 15 September 2026

Core Guarantee

SemaFore mobile clients encrypt private and group messages on the sender’s device before transmission. The core messaging server receives and routes ciphertext only and has no key material with which to decrypt it. Decryption occurs on recipient devices under the control of their private keys.

Portal-admin broadcasts follow a separate sender path. The administrator’s browser fetches recipient-device key bundles through the portal and creates an independent encrypted envelope for each device. The portal server rejects plaintext message fields, so only ciphertext envelopes cross the Cloudflare-hosted portal boundary and reach the core messaging server. See Broadcast Messages for the complete boundary.

Forward secrecy is a current platform property. The live Double Ratchet implementation means a key compromised today cannot decrypt yesterday’s messages.

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
  • Delivery records: message, sender, and recipient-device identifiers plus delivery timestamps and status needed to route and account for ciphertext
  • Audit metadata: defined security and administrative events; broadcast entries include message, envelope, and recipient counts, but never message content or recipient lists

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

Organisation Isolation

SemaFore supports multi-organisation membership. A user can belong to more than one organisation and switch between organisation contexts in the app. Each context shows only that organisation’s members and conversations, and the server enforces tenant isolation for the active organisation context.

Multi-organisation membership does not create separate cryptographic identities. A device has one key bundle across all organisations; organisation membership controls which conversations and members are visible in each context.

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 automatically when the permitted key age is reached
  • One-Time Pre-Keys (OPKs): ephemeral keys consumed one at a time when recipients establish new sessions, replenished automatically when supply runs low

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