Broadcast Messages

Broadcast Delivery Model

Organisation administrators can send organisation-wide announcements to all approved members. From a cryptographic perspective, broadcasts do not use a shared group key or broadcast key. Instead, each member receives their own independently encrypted copy of the message.

For the portal workflow that uses this delivery model, see Broadcast.

How It Works

When an organisation administrator sends a broadcast:

1. The portal submits the message to the server: POST /api/portal/orgs/{orgID}/broadcast with message identifier and ciphertext
2. The server queries the list of all active members in the organisation
3. For each member with registered devices, the server:
   • Fetches that member’s current key bundle (one per device)
   • Encrypts the broadcast message to that device using the member’s key bundle (via X3DH)
   • Routes the encrypted message to the member’s devices as if it were a point-to-point message
4. The server records audit metadata: sender, timestamp, organisation, message identifier, recipient count—but not message content

Cryptographic Properties

Each broadcast copy is independently encrypted:

• No shared group key: Unlike some group messaging protocols, SemaFore does not generate or store a shared group encryption key
• Per-recipient session: Each member’s copy uses that member’s individual session key, derived from their key bundle
• Plaintext-blind relay: The server routes N encrypted copies (one per recipient) without reading content
• Forward secrecy per recipient: Each recipient’s copy follows its own Double Ratchet independent of other recipients, so forward secrecy applies per recipient

Advantages and Trade-offs

Advantages:

• The server remains plaintext-blind; it cannot read broadcast content even if it wanted to
• Members joining after a broadcast cannot request a replay of the ciphertext (there is no shared group state to recover)
• Audit logs are fine-grained: the server knows exactly who received what message at what time
• Per-recipient forward secrecy means compromising one recipient’s device does not compromise past broadcasts to other recipients

Trade-offs:

• Sending a broadcast to N members requires encrypting the message N times (once per device per member)
• The server must perform N routing operations (one per device)
• Storage cost is proportional to the number of recipients

The trade-off is intentional: scalability through independent encryption per recipient is superior to group key management for organisations that need per-recipient audit trails and forward secrecy that is independent across recipients.