End-to-end encryption, and what I didn't build
11 October 2026
Kodosi rooms hold shared terminals, a conversation and tasks, and they are end-to-end encrypted. In October I reviewed the design against Signal, MLS, Matrix and Keybase. The useful result was two lists: what to build, and what not to.
Two rules sorted things onto the lists. Protect against outsiders first. And security must not add steps for the person using it.
What I built
Rooms keep working when a member is away. A device list used to be valid for one day, so one member away for longer stopped the room for everyone.
Identities are checked against the friend record. A recovery key opens the room history on a new device. Key exchange uses X25519 next to ML-KEM-768, so the keys hold if either one is broken. And the design now has a written spec and threat model.
What I didn’t build
A message ratchet, a public key log, MLS and a PAKE. Each one protects against something real, and each one costs steps, code or both. They are not in the first version.
The old code paths went too. PR #25 removed the last compatibility path. The first public release was still ahead, so there was nothing old to stay compatible with.
Known limits, in public
CRYPTOGRAPHY.md has a numbered list of what the design does not do. A link code has 60 bits, stretched with PBKDF2 at 2^20 rounds, which leaves the backend about 2^80 work to guess one. The recovery key has 160 bits. Room content has no forward secrecy. The design hasn’t been audited yet.