Threat Model - Speakeasy.im

Speakeasy has not completed an independent security audit. The claims below describe the design and current implementation honestly, including its known weak points. Treat the current release as beta software.

The one-paragraph version

Private conversations in Speakeasy — direct messages, private group rooms, their attachments, and voice/video/screen-share media — are end-to-end encrypted with MLS (Messaging Layer Security, RFC 9420). The server relays and stores ciphertext it cannot read. But end-to-end encryption does not hide everything: the server still sees who talks to whom, when, and how much. Public forums are not encrypted at all, by design. And like every E2EE system, none of this protects you from malware running on your own computer.

Room types matter

Space	Content encryption	Who controls membership
Direct messages	End-to-end (MLS)	The participants, cryptographically
Private group rooms	End-to-end (MLS)	The room owner, cryptographically
Public rooms	End-to-end (MLS) once joined	The server (access control), by design
Public forums	None — plaintext on the server	The server

Forums are for public long-form discussion; treat everything posted there as public. Public rooms get content confidentiality (the server cannot read messages) but the server decides who is admitted. Private rooms and DMs are the strongest tier: admission requires the room owner's cryptographic authorization, which every member's client verifies independently.

What Speakeasy protects

Private message content. DM and private-room text is encrypted with MLS before it leaves your device. The server stores opaque ciphertext.
Attachments in private conversations. Files and thumbnails are encrypted client-side. The server sees only the encrypted blob, its size, and a hash of the ciphertext — not the filename, type, or content.
Voice, video, and screen-share media. Media frames are encrypted with MLS-derived keys before they reach the media server (WebRTC insertable streams). The SFU routes encrypted frames it cannot decrypt. This is frame-level end-to-end encryption, not just transport (TLS/DTLS) encryption to the server.
Private room membership integrity. Adding a device to a private room requires an authorization signed by the room owner's device, and every member's client verifies that signature against a locally pinned trust root. A compromised server cannot quietly add itself or anyone else to your private room.
Key material in transit. Linking a new device never moves private keys across the network — only signed public credentials. History transfer between your own devices moves encrypted content the server merely relays.

What the server can still see

Run by you or not, the server is a fully-informed metadata observer. Even for end-to-end encrypted conversations, it stores and can see:

Account existence, email addresses, and IP addresses of connecting clients
Which users and devices are in which rooms and groups (the roster), and when membership changed
Who sent each message, to which room, at exactly what time, and whether it was a chat message or a protocol/control message
Per-device delivery and read timestamps
Exact ciphertext sizes — message lengths and file sizes are not hidden
Voice/video session timing and bandwidth (who was in a call, for how long)
Everything in public forums, in plaintext

If your threat model requires hiding who talks to whom from the server, Speakeasy does not provide that. It provides content confidentiality on infrastructure you control.

If the server is compromised (or hostile)

What a malicious server, or an attacker who has taken one over, cannot do:

Read private message content, private attachments, or room media — past or future
Add a device to a private room or DM without the owner-signed authorization that member clients verify
Remove cryptographic membership or forge roster changes without genuine signed MLS commits

What it can do:

Withhold delivery. A malicious server can silently drop messages to a member. Clients can detect partial withholding (sequence gaps), but a total blackout — where a device receives nothing at all — is not detectable by that device. Speakeasy's guarantees cover confidentiality and membership integrity, not delivery availability.
See all the metadata listed above, and hand it to whoever controls the machine
Control admission to public rooms and read all forum content
Refuse service entirely

If your device is compromised

End-to-end encryption protects data in transit and on the server — not on an endpoint an attacker controls. Speakeasy follows the same isolation model as Signal Desktop: device keys are protected with OS-level secure storage (DPAPI on Windows, keychain/libsecret elsewhere), which defends against a different OS user or offline disk theft, but malware running as your own OS user can access what your client can access. That is inherent to desktop E2EE apps, and we would rather say it plainly than imply otherwise.

Current limitation, stated honestly: Speakeasy does not yet support revoking a single lost or compromised device. Today the recovery path is a full identity replacement — re-authenticating with your password, revoking all your devices, and rekeying your conversations. Scoped single-device revocation is designed and on the roadmap, but it is not shipped, so we do not claim it.

Devices and keys

Every device has its own identity and signing keys, generated on that device.
Desktop clients seal key storage with the operating system's secure storage API.
The web client wraps its key material using WebAuthn PRF (hardware-bound, preferred) or a key derived from a passphrase via Argon2id — the passphrase is never sent to the server, and no unwrapped key is ever persisted.
New devices are linked by transferring signed public credentials only; approval currently requires your first (bootstrap) device.

Authentication and abuse resistance

Sessions use hardened cookies (HttpOnly, Secure in production).
Two-factor authentication (TOTP authenticator apps + backup codes) is supported.
Rate limiting applies per-IP to authentication and connection handshakes, and per-user to chat, media, admin, and E2EE operations.

What server admins can and cannot do

Admins hold access-control power: they can create, rename, and delete rooms, kick users from server-controlled spaces, and manage accounts. Access control is deliberately separate from encryption: no admin permission grants the ability to decrypt private conversations or to forge membership in a private room — those require signed MLS operations that clients verify. Forum content, and all the metadata above, is within an admin's reach.

Audit status

Speakeasy uses an established Rust implementation of MLS (mls-rs) compiled to WebAssembly rather than homegrown cryptography, and internal adversarial testing runs against the membership and delivery paths. No independent third-party audit has been completed yet. An audit is a funding goal, not a completed fact, and until one exists you should weigh that in what you use Speakeasy for.

Reporting

Found a hole in any claim on this page? That is exactly what we want to know: security contact & responsible disclosure.