How Proteus works
Proteus is a double ratchet protocol derived from the Signal specification:- Identity keypair — each device has a long-lived Curve25519 identity keypair stored in the keystore.
- PreKeys — a supply of short-lived one-time Curve25519 keypairs published to the server. When a peer wants to initiate a session, it fetches one of these prekeys and performs an X3DH (Extended Triple Diffie-Hellman) handshake.
- Session state — once initiated, the session maintains a ratchet chain. Every encrypted message advances the chain, producing a new message key and destroying the old one (forward secrecy).
- Last-resort prekey — a permanent prekey at ID
u16::MAX(65535) used as a fallback when all one-time prekeys have been consumed.
CoreCrypto types
ProteusCentral
ProteusCentral (in crypto/src/proteus.rs) is the session manager for the Proteus
protocol. It is the Proteus counterpart to the MLS Session.
Session: ProteusCentral does not own its keystore. It borrows
the Database from CoreCrypto on every operation. This means MLS and Proteus share the
same encrypted database.
ProteusCentral is stored inside CoreCrypto behind an Arc<Mutex<Option<ProteusCentral>>>
and is only populated after TransactionContext::proteus_init() is called.
ProteusConversationSession
A ProteusConversationSession wraps a single proteus_wasm::session::Session and its
string identifier:
ProteusConversationSession.
Session lifecycle
Initiating from a prekey (outbound first message)
Receiving a first message (inbound handshake)
When the first message from a new peer arrives, the Proteus session does not yet exist locally. Useproteus_session_from_message to create the session and decrypt in one step:
Ongoing encrypt / decrypt
Batch encrypt
To send the same plaintext to multiple devices (the common case in a Wire conversation), use the batch API to minimise FFI round-trips:PreKey management
new_prekey_auto calls return 3, 7, and 12.
MLS vs Proteus — when to use which
Use MLS when...
- You need true group messaging with a shared cryptographic state
- Group membership changes frequently (add/remove members)
- You require forward secrecy and post-compromise security guarantees defined by RFC 9420
- You are building new features; MLS is the preferred protocol going forward
- The conversation has more than two participants
Use Proteus when...
- You need backwards compatibility with existing Wire clients that do not yet support MLS
- You are dealing with a strictly 1:1 channel and want the lower protocol overhead of a simple double ratchet
- You need to interoperate with Cryptobox-based (legacy Wire backend) sessions
- A migration path is in progress and you need Proteus as a temporary fallback