Forward secrecy in plain English
Forward secrecy means a key compromised tomorrow can't read messages from yesterday. It's a property most workspace tools don't have. Here's what it is, why it matters, and how groups achieve it.
Forward secrecy is the property that a key compromised today cannot read messages from before today. It sounds like a technicality. It's the difference between a single bad day costing you one conversation and costing you everything you've ever sent.
The intuition
Imagine you use the same physical key to lock every drawer in your office. If someone steals that key, they can open every drawer — including every drawer you'd already locked yesterday, last year, ten years ago. Your past is as exposed as your present.
Now imagine the lock rotates every day. Today's key opens today's drawer; tomorrow's key opens tomorrow's. If someone steals tomorrow's key, they can't go back and open yesterday's. Each day's data is sealed under that day's key alone, and the keys aren't connected.
That's forward secrecy. The key for any given moment in time doesn't unlock the past.
Why most workspace tools don't have it
Forward secrecy requires deriving fresh keys frequently — every message, or every group membership change, or at minimum every session. That's work the workspace tool would have to do continuously, and it complicates almost every server-side feature (search, AI, support). Most tools chose features.
The visible consequence: a vendor breach that exposes server-side keys exposes not just future messages but the entire archive. The blast radius of a breach is everything stored to date.
Signal popularized forward secrecy in mainstream messaging through its Double Ratchet design — a fresh key per message, derived in a way the previous key can't reconstruct. The price is complexity. The payoff is that a stolen key today doesn't decrypt yesterday's messages even if the vendor wanted to help.
Group rooms are harder
Forward secrecy for one-on-one messaging was the easier problem. For groups — a marketing team channel, a board room, a matter team, a family thread — the math gets harder, because every member needs to derive the same key to read the same message, and the key needs to roll forward through changes in membership.
The IETF's Messaging Layer Security (MLS) protocol — published as RFC 9420 in 2023 — solved this. MLS gives groups three properties simultaneously: every member can derive the current key, every membership change rolls the key forward (so past members lose access to future messages), and a member whose key is compromised can be moved past in the ratchet (so the compromise doesn't permanently follow the group).
Koaich uses MLS for group rooms. See What's MLS and why does it matter for workspace privacy for the deeper version.
What this looks like in practice
A contractor joins your team for a project. You add them to the matter room. They can read messages from the moment they joined — not before. Their device has the post-join group key but not the pre-join one.
The project ends. You remove them. They can read messages up to the moment they left — not after. The group key rolls forward on removal; their device has the pre-removal key but not the post-removal one.
If their device is later compromised — phone stolen, malware installed, ex-employee acting in bad faith — the attacker can decrypt the slice of conversation that contractor was in. They can't decrypt the time before they joined or after they left. The exposure is scoped exactly to what their access genuinely was.
Most workspace tools — Slack, Notion, Teams, Google Workspace — don't have this property. A leaked workspace key, an over-permissioned admin account, an old session token can reach the full archive. The blast radius is everything.