Glossia is an open protocol for end-to-end encrypted messaging between people who cannot afford to be overheard. This document specifies version 4.0 of the protocol: how clients identify one another, agree on keys, encrypt messages and move them through the relay network, and what each part of the system can and cannot learn.
The specification is public so that anyone can check that Glossia does what we say it does. It is written to be read by implementers and auditors, but the overview in each section is meant for anyone.
Design goals
- Confidentiality. Only the people in a conversation can read it. Relays, network observers and Frothly cannot.
- Forward secrecy and recovery. Stealing a device’s keys today does not reveal yesterday’s messages, and a conversation heals itself after a compromise ends.
- Post-quantum confidentiality. Messages recorded today stay private even if a large quantum computer is built later. This is new in 4.0.
- Minimal metadata. No single relay learns both who sent a message and who received it. Message sizes and timing reveal as little as practical.
- Poor networks first. Glossia works on slow, expensive and intermittent connections, and on old phones.
- Seized devices. A device taken at a border should reveal as little as possible, for as short a time as possible.
- No identifiers we do not need. Glossia does not use phone numbers or email addresses. People find each other by exchanging contact codes, or through optional usernames.
Non-goals
- Hiding everything from a global observer. An adversary that can watch every network link at once can still learn something from timing. Optional cover traffic and delivery delays make this harder, not impossible (see Security considerations).
- Protecting a compromised device. If a device is controlled by an attacker while it is unlocked, the attacker can read what its owner reads.
- Anonymity from your contacts. The people you talk to know it is you. Glossia protects conversations from outsiders, not from their participants.
Conventions
The key words MUST, MUST NOT, SHOULD, SHOULD NOT and MAY are used as described in RFC 2119. Byte strings are written in hexadecimal, || means concatenation, and all integers are unsigned and big-endian unless stated otherwise.
Contents
- 2ArchitectureClients, relays, bridges, the directory and the key transparency log, and what each one sees.
- 3Identities and devicesIdentity keys, device keys, prekeys and safety numbers.
- 4The hybrid handshakeHow two clients agree on a shared secret that resists both today’s attacks and tomorrow’s quantum computers.
- 5Message keys and the ratchetHow every message gets its own key, and how a conversation recovers after a compromise.
- 6Message format and paddingThe envelope every message travels in, and why every message is padded to one of five sizes.
- 7Routing through relaysHow clients choose three relays for each message, and how layered encryption keeps any one of them from seeing the whole route.
- 8Delivery on poor connectionsStore-and-forward mailboxes, resumable transfers and the changes that make 4.0 faster on slow networks.
- 9GroupsEncrypted groups of up to 1,000 people, where relays cannot see who is a member.
- 10Key transparencyA public, append-only log that makes it impossible to quietly swap someone’s keys.
- 11The relay directoryHow relays are described, signed into an hourly directory and chosen by clients.
- 12Versions and downgrade protectionHow clients agree on a protocol version, and why an attacker cannot force an older one.
- 13Security considerationsThe threats Glossia defends against, the risks it accepts and what it cannot do.
- 14Changes and historyWhat changed in 4.0, the protocol’s version history and acknowledgments.