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 registered recipient device receives its 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 administrator’s browser requests the eligible recipient-device key bundles through the portal.
2. For each recipient device, the browser validates the signed pre-key and creates an independent X3DH-derived AES-256-GCM encrypted envelope.
3. The browser submits the message identifier and completed ciphertext-envelope list through the portal to the messaging service. The portal server rejects plaintext message fields.
4. The core server validates envelope structure and confirms that each recipient and device belongs to the organisation. It does not inspect or transform ciphertext.
5. The server fans out the opaque envelopes through the normal per-device delivery queue, including offline delivery on reconnect.
6. The server records audit metadata: sender, timestamp, organisation, message identifier, envelope count, and recipient count, but not message content or envelope contents.

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-device envelope: Each registered recipient device receives an independently derived X3DH/AES-256-GCM envelope
• Plaintext-blind relay: The server routes one encrypted copy per recipient device without reading content
• Recipient isolation: Compromise of one recipient envelope does not reveal copies encrypted for other devices

Advantages and Trade-offs

Advantages:

• The portal and core server remain plaintext-blind; neither receives the broadcast plaintext
• 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
• Compromising one recipient device does not reveal the independently encrypted copies sent to other devices

Trade-offs:

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

The trade-off is intentional: independent per-device encryption avoids a shared broadcast key and preserves a distinct delivery and audit record for each intended recipient.