OMEMO and end to end encryption

Encrypting the wire is not the same as encrypting the conversation. However well each hop is protected, a federated message may pass more than just one server, and the extension that defines OMEMO states the problem plainly: users have an interest in securing their communication from any intermediate host. Its answer is end-to-end encryption, protecting everything exchanged between sender and receiver against passive and active attackers, servers and network nodes included.

The extension is XEP-0384, OMEMO Encryption, and like every addition to the frozen RFC core it carries a status, Experimental, Proposed, Stable or Final; how an idea climbs that ladder is a story of its own. It defines end-to-end encryption for one-to-one chats, and for group chats where each participant may hold several clients on one account.

What the older schemes left undone

OMEMO did not arrive in a vacuum. The specification opens by counting the two end-to-end schemes already in common use, Off-the-Record messaging and OpenPGP, and measuring what each costs. An OTR session existed between exactly two clients, so the history never synchronised across the parties’ other clients, and a chat required both participants to be online at once, a consequence of OTR’s rolling key agreement. OTRv4 addressed some of this. OpenPGP had neither mobility problem, but provided no forward secrecy, was vulnerable to replay attacks, and used a wire format defined by convention rather than standardisation, a complaint later resolved by another extension, OpenPGP for XMPP.

Why does one account need so many keys?

Because the address does not stop at the person. A JID names a person, the server that holds the account, and the particular device in use right now, and OMEMO encrypts at that granularity. The protocol maintains a separate, long-standing encrypted session with each device of each contact, and with the sender’s own devices. Those sessions do not carry the conversation, they are key transport channels. Each message gets a fresh, randomly generated key, and a header is attached for every device meant to receive it, holding the payload key sealed with that device’s session. It all travels as an ordinary <message> stanza; the encrypted payload, identical for all recipients, is included only once, keeping the overhead down.

A ratchet that tolerates silence

The engine underneath is the Double Ratchet, specified by Trevor Perrin and Moxie Marlinspike, first published as the Axolotl protocol, its specification in the public domain. What OMEMO takes from it is patience. Messages that are lost, arrive out of order, or are sent while the recipient is offline are handled transparently. The key exchange with a new device happens just in time, on the first message, which already carries encrypted content. In combination with Message Carbons and Message Archive Management, the history reads the same on every client.

What OMEMO promises, plainly

The OMEMO specification sets its guarantees out like a contract. Confidentiality: only sender and receiver read a message. Integrity: no intermediate node changes one unnoticed. Authentication: each peer can authenticate the other. Break-in recovery: a compromised session recovers after a few communication rounds. Asynchronicity: nothing depends on anyone being online. Then come the caveats. Forward secrecy is described as weak, the session key being protected only once both parties complete the key exchange. Deniability rests on X3DH, called weakly offline deniable, with no online deniability, as far as the research shows.

The cases OMEMO is not meant to face get equal candour. An attacker with permanent access to a device can extract decrypted messages from the application’s database; if the access is temporary, break-in recovery eventually restores security. A lost device showing messages on the notification screen hands them over without breaking any cryptography. Denial of service is out of scope, and one entry still reads “tbc”, a reminder that a specification is a living document.

Where do the key bundles live?

A session needs key material before it starts, and something must distribute it. That role belongs to publish-and-subscribe: the specification relies on Publish-Subscribe and its personal variant, the Personal Eventing Protocol, to publish and acquire key bundles. A dedicated key server component could take the job in the future, the text notes, but that is a possibility, not the present. Trust management is called a difficult topic and left out of scope, with consequences that surface below.

Arithmetic only a library author needs

Section 4 of the XEP changes register, and says so: readers who do not intend to build an OMEMO-compatible library can safely skip it. It contains HKDF-SHA-256 stretching 80 bytes from a message key into a 32-byte encryption key, a 32-byte authentication key and a 16-byte IV; AES-256-CBC with PKCS#7 padding; an HMAC-SHA-256 truncated to 128 bits. One note orders the protobuf structures serialised exactly once, later steps reusing that byte sequence. The curve rules require converting between Curve25519 and Ed25519 through the birational map defined in RFC 7748. One divergence from practice is flagged: libsignal includes XEdDSA but does not use it by default, and must be modified for OMEMO compatibility.

The check that decides everything

The threat model names its use cases without embarrassment: information under strict embargo moving inside an organisation whose server administrator is not cleared to see it, or a couple exchanging intimate messages away from the administrator’s eyes. Against attackers able to read, modify, replay, delay or delete messages, the protocol holds; against metadata and traffic analysis it does not try. The decisive sentence is an aside: the quality of the verification of the participants’ identity keys determines the level of protection OMEMO offers. Before trusting a conversation to OMEMO, find where the chosen client verifies a contact’s identity key, and do it for every device.

xmpp.org

xmpp.org is where the XMPP Standards Foundation publishes its extensions, the numbered documents layered on top of the RFC core. The page for XEP-0384 carries the full specification: motivation, threat model, guarantees with their caveats, a protocol definition detailed enough to build a library from, six authors named.