Harvest now, decrypt later
Encrypted traffic is recorded today and kept until the machine that breaks it exists. Against that strategy, changing encryption ten years from now is useless: what is already recorded is already lost. The only answer is to encrypt differently from the first message.
Two locks, not one
Every conversation opens a classic Noise XX channel over X25519 and, in parallel, an ML-KEM-768 exchange. The final key derives from both. Reading a message means breaking both: one holds against today's computers, the other against what comes next.
ML-KEM is the NIST standard, FIPS 203, published in August 2024.
The carrier cannot open it
The server holds no private key. It keeps a directory of public keys and relays opaque blocks: it sees who to whom in order to route, never the content. This is not a privacy policy promise, it is the limit of what the code can do.
Groups and calls too
Rooms use MLS, the IETF group messaging standard: the key changes on every join and every leave. Calls go through a server we host ourselves in Beauharnois, with no third party service on the path.
Technical annex
- Handshake
- Hybrid Noise XX, X25519 + ML-KEM-768
- Encryption
- ChaCha20-Poly1305, BLAKE2s fingerprints
- Groups
- MLS RFC 9420, key rotated on every member change
- Server
- Public key directory, opaque block relay
- Calls
- Self hosted SFU, token signed by your account key
- External dependencies
- None