Depend on Olm instead of Axolotl.
There are two main end-to-end encryption schemes in common use in the XMPP ecosystem, Off-the-Record (OTR) messaging (&xep0364;) and OpenPGP (&xep0027;). OTR has significant usability drawbacks for inter-client mobility. As OTR sessions exist between exactly two clients, the chat history will not be synchronized across other clients of the involved parties. Furthermore, OTR chats are only possible if both participants are currently online, due to how the rolling key agreement scheme of OTR works. OpenPGP, while not suffering from these mobility issues, does not provide any kind of forward secrecy and is vulnerable to replay attacks. Additionally, PGP over XMPP uses a custom wireformat which is defined by convention rather than standardization, and involves quite a bit of external complexity.
-This XEP defines a protocol that leverages axolotl encryption to provide multi-end to multi-end encryption, allowing messages to be synchronized securely across multiple clients, even if some of them are offline.
++ There are two main end-to-end encryption schemes in common use in the XMPP + ecosystem, Off-the-Record (OTR) messaging (&xep0364;) and OpenPGP + (&xep0027;). OTR has significant usability drawbacks for inter-client + mobility. As OTR sessions exist between exactly two clients, the chat + history will not be synchronized across other clients of the involved + parties. Furthermore, OTR chats are only possible if both participants are + currently online, due to how the rolling key agreement scheme of OTR + works. OpenPGP, while not suffering from these mobility issues, does not + provide any kind of forward secrecy and is vulnerable to replay attacks. + Additionally, PGP over XMPP uses a custom wireformat which is defined by + convention rather than standardization, and involves quite a bit of + external complexity. +
++ This XEP defines a protocol that leverages &olm; encryption to provide + multi-end to multi-end encryption, allowing messages to be synchronized + securely across multiple clients, even if some of them are offline. Olm + is a cryptographic double ratched protocol based on work by Trevor Perrin + and Moxie Marlinspike first published as the Axolotl protocol. +
The general idea behind this protocol is to maintain separate, long-standing axolotl-encrypted sessions with each device of each contact (as well as with each of our other devices), which are used as secure key transport channels. In this scheme, each message is encrypted with a fresh, randomly generated encryption key. An encrypted header is added to the message for each device that is supposed to receive it. These headers simply contain the key that the payload message is encrypted with, and they are seperately encrypted using the session corresponding to the counterpart device. The encrypted payload is sent together with the headers as a <message> stanza. Individual recipient devices can decrypt the header item intended for them, and use the contained payload key to decrypt the payload message.
-As the encrypted payload is common to all recipients, it only has to be included once, reducing overhead. Furthermore, axolotl's transparent handling of messages that were lost or received out of order, as well as those sent while the recipient was offline, is maintained by this protocol. As a result, in combination with &xep0280; and &xep0313;, the desired property of inter-client history synchronization is achieved.
-OMEMO version 0 uses v3 messages of the axolotl protocol. Instead of an axolotl key server, PEP (&xep0163;) is used to publish key data.
++ The general idea behind this protocol is to maintain separate, + long-standing Olm-encrypted sessions with each device of each contact + (as well as with each of our other devices), which are used as secure key + transport channels. In this scheme, each message is encrypted with a + fresh, randomly generated encryption key. An encrypted header is added to + the message for each device that is supposed to receive it. These headers + simply contain the key that the payload message is encrypted with, and + they are seperately encrypted using the session corresponding to the + counterpart device. The encrypted payload is sent together with the + headers as a <message> stanza. Individual recipient devices can + decrypt the header item intended for them, and use the contained payload + key to decrypt the payload message. +
++ As the encrypted payload is common to all recipients, it only has to be + included once, reducing overhead. Furthermore, Olm's transparent handling + of messages that were lost or received out of order, as well as those sent + while the recipient was offline, is maintained by this protocol. As a + result, in combination with &xep0280; and &xep0313;, the desired property + of inter-client history synchronization is achieved. +
++ OMEMO currently uses version 1 Olm protocol. Instead of an Axolotl key + server, &xep0163; (PEP) is used to publish key data. +
The first thing that needs to happen if a client wants to start using OMEMO is they need to generate an IdentityKey and a Device ID. The IdentityKey is a Curve25519 public/private Key pair. The Device ID is a randomly generated integer between 1 and 2^31 - 1.
++ The first thing that needs to happen if a client wants to start using + OMEMO is they need to generate an IdentityKey and a Device ID. The + IdentityKey is a &curve25519; public/private Key pair. The Device ID is a + randomly generated integer between 1 and 2^31 - 1. +
In order to determine whether a given contact has devices that support OMEMO, the devicelist node in PEP is consulted. Devices MUST subscribe to 'urn:xmpp:omemo:0:devicelist' via PEP, so that they are informed whenever their contacts add a new device. They MUST cache the most up-to-date version of the devicelist.
@@ -166,16 +213,29 @@A random preKeyPublic entry is selected, and used to build an axolotl session.
+A random preKeyPublic entry is selected, and used to build an Olm session.
In order to send a chat message, its <body> first has to be encrypted. The client MUST use fresh, randomly generated key/IV pairs with AES-128 in Galois/Counter Mode (GCM). For each intended recipient device, i.e. both own devices as well as devices associated with the contact, this key is encrypted using the corresponding long-standing axolotl session. Each encrypted payload key is tagged with the recipient device's ID. This is all serialized into a MessageElement, which is transmitted in a <message> as follows:
++ In order to send a chat message, its <body> first has to be + encrypted. The client MUST use fresh, randomly generated key/IV pairs with + AES-128 in Galois/Counter Mode (GCM). + The 16 bytes key and the GCM authentication tag (The tag SHOULD have at least + 128 bit) are concatenated and for each intended recipient device, + i.e. both own devices as well as devices associated with the contact, the + result of this concatenation is encrypted using the corresponding + long-standing Olm session. Each encrypted payload key/authentication tag + tuple is tagged with the recipient device's ID. The key element MUST be + tagged with a prekey attribute set to true if a PreKeyOlmMessage is being + used. This is all serialized into a MessageElement, which is transmitted + in a <message> as follows: +
The client may wish to transmit keying material to the contact. This first has to be generated. The client MUST generate a fresh, randomly generated key/IV pair. For each intended recipient device, i.e. both own devices as well as devices associated with the contact, this key is encrypted using the corresponding long-standing axolotl session. Each encrypted payload key is tagged with the recipient device's ID. This is all serialized into a KeyTransportElement, omitting the <payload> as follows:
++ The client may wish to transmit keying material to the contact. This first + has to be generated. The client MUST generate a fresh, randomly generated + key/IV pair. The 16 bytes key and the GCM authentication tag (The tag + SHOULD have at least 128 bit) are concatenated and for each intended + recipient device, i.e. both own devices as well as devices associated + with the contact, this key is encrypted using the corresponding + long-standing Olm session. Each encrypted payload key/authentication tag + tuple is tagged with the recipient device's ID. The key element MUST be + tagged with a prekey attribute set to true if a PreKeyOlmMessage is being + used This is all serialized into a KeyTransportElement, omitting the + <payload> as follows: +
This KeyTransportElement can then be sent over any applicable transport mechanism.
When an OMEMO element is received, the client MUST check whether there is a <key> element with an rid attribute matching its own device ID. If this is not the case, the element MUST be silently discarded. If such an element exists, the client checks whether the element's contents are a PreKeyWhisperMessage.
+When an OMEMO element is received, the client MUST check whether there is a <key> element with an rid attribute matching its own device ID. If this is not the case, the element MUST be silently discarded. If such an element exists, the client checks whether the element's contents are a PreKeyOlmMessage.
If this is the case, a new session is built from this received element. The client SHOULD then republish their bundle information, replacing the used PreKey, such that it won't be used again by a different client. If the client already has a session with the sender's device, it MUST replace this session with the newly built session. The client MUST delete the private key belonging to the PreKey after use.
-If the element's contents are a WhisperMessage, and the client has a session with the sender's device, it tries to decrypt the WhisperMessage using this session. If the decryption fails or if the element's contents are not a WhisperMessage either, the OMEMO element MUST be silently discarded.
-If the OMEMO element contains a <payload>, it is an OMEMO message element. The client tries to decrypt the base 64 encoded contents using the key extracted from the <key> element. If the decryption fails, the client MUST silently discard the OMEMO message. If it succeeds, the decrypted contents are treated as the <body> of the received message.
+If the element's contents are a OlmMessage, and the client has a session with the sender's device, it tries to decrypt the OlmMessage using this session. If the decryption fails or if the element's contents are not a OlmMessage either, the OMEMO element MUST be silently discarded.
+If the OMEMO element contains a <payload>, it is an OMEMO message element. The client tries to decrypt the base64 encoded contents using the key and the authentication tag extracted from the <key> element. If the decryption fails, the client MUST silently discard the OMEMO message. If it succeeds, the decrypted contents are treated as the <body> of the received message.
If the OMEMO element does not contain a <payload>, the client has received a KeyTransportElement. The key extracted from the <key> element can then be used for other purposes (e.g. encrypted file transfer).
Before publishing a freshly generated Device ID for the first time, a device MUST check whether that Device ID already exists, and if so, generate a new one.
-Clients SHOULD NOT immediately fetch the bundle and build a session as soon as a new device is announced. Before the first message is exchanged, the contact does not know which PreKey has been used (or, in fact, that any PreKey was used at all). As they have not had a chance to remove the used PreKey from their bundle announcement, this could lead to collisions where both Alice and Bob pick the same PreKey to build a session with a specific device. As each PreKey SHOULD only be used once, the party that sends their initial PreKeyWhisperMessage later loses this race condition. This means that they think they have a valid session with the contact, when in reality their messages MAY be ignored by the other end. By postponing building sessions, the chance of such issues occurring can be drastically reduced. It is RECOMMENDED to construct sessions only immediately before sending a message.
-As there are no explicit error messages in this protocol, if a client does receive a PreKeyWhisperMessage using an invalid PreKey, they SHOULD respond with a KeyTransportElement, sent in a <message> using a PreKeyWhisperMessage. By building a new session with the original sender this way, the invalid session of the original sender will get overwritten with this newly created, valid session.
-If a PreKeyWhisperMessage is received as part of a &xep0313; catch-up and used to establish a new session with the sender, the client SHOULD postpone deletion of the private key corresponding to the used PreKey until after MAM catch-up is completed. If this is done, the client MUST then also send a KeyTransportMessage using a PreKeyWhisperMessage before sending any payloads using this session, to trigger re-keying. (as above) This practice can mitigate the previously mentioned race condition by preventing message loss.
+Clients SHOULD NOT immediately fetch the bundle and build a session as soon as a new device is announced. Before the first message is exchanged, the contact does not know which PreKey has been used (or, in fact, that any PreKey was used at all). As they have not had a chance to remove the used PreKey from their bundle announcement, this could lead to collisions where both Alice and Bob pick the same PreKey to build a session with a specific device. As each PreKey SHOULD only be used once, the party that sends their initial PreKeyOlmMessage later loses this race condition. This means that they think they have a valid session with the contact, when in reality their messages MAY be ignored by the other end. By postponing building sessions, the chance of such issues occurring can be drastically reduced. It is RECOMMENDED to construct sessions only immediately before sending a message.
+As there are no explicit error messages in this protocol, if a client does receive a PreKeyOlmMessage using an invalid PreKey, they SHOULD respond with a KeyTransportElement, sent in a <message> using a PreKeyOlmMessage. By building a new session with the original sender this way, the invalid session of the original sender will get overwritten with this newly created, valid session.
+If a PreKeyOlmMessage is received as part of a &xep0313; catch-up and used to establish a new session with the sender, the client SHOULD postpone deletion of the private key corresponding to the used PreKey until after MAM catch-up is completed. If this is done, the client MUST then also send a KeyTransportMessage using a PreKeyOlmMessage before sending any payloads using this session, to trigger re-keying. (as above) This practice can mitigate the previously mentioned race condition by preventing message loss.
As the asynchronous nature of OMEMO allows decryption at a later time to currently offline devices client SHOULD include a &xep0334; <store /> hint in their OMEMO messages. Otherwise, server implementations of &xep0313; will generally not retain OMEMO messages, since they do not contain a <body />
For details on axoltol, see the specification and reference implementation.
-The axolotl library's reference implementation (and presumably its ports to various other platforms) uses a trust model that doesn't work very well with OMEMO. For this reason it may be desirable to have the library consider all keys trusted, effectively disabling its trust management. This makes it necessary to implement trust handling oneself.
+ ++ The Olm library's reference implementation (and presumably its ports to + various other platforms) uses a trust model that doesn't work very well with + OMEMO. For this reason it may be desirable to have the library consider all + keys trusted, effectively disabling its trust management. This makes it + necessary to implement trust handling oneself. +
Clients MUST NOT use a newly built session to transmit data without user intervention. If a client were to opportunistically start using sessions for sending without asking the user whether to trust a device first, an attacker could publish a fake device for this user, which would then receive copies of all messages sent by/to this user. A client MAY use such "not (yet) trusted" sessions for decryption of received messages, but in that case it SHOULD indicate the untrusted nature of such messages to the user.
When prompting the user for a trust decision regarding a key, the client SHOULD present the user with a fingerprint in the form of a hex string, QR code, or other unique representation, such that it can be compared by the user.
While it is RECOMMENDED that clients postpone private key deletion until after MAM catch-up and this standards mandates that clients MUST NOT use duplicate-PreKey sessions for sending, clients MAY delete such keys immediately for security reasons. For additional information on potential security impacts of this decision, refer to
In order to be able to handle out-of-order messages, the axolotl stack has to cache the keys belonging to "skipped" messages that have not been seen yet. It is up to the implementor to decide how long and how many of such keys to keep around.
++ In order to be able to handle out-of-order messages, the Olm stack has to + cache the keys belonging to "skipped" messages that have not been seen yet. + It is up to the implementor to decide how long and how many of such keys to + keep around. +
This document requires no interaction with the Internet Assigned Numbers Authority (IANA).
@@ -250,7 +333,8 @@Big thanks to Daniel Gultsch for mentoring me during the development of this protocol. Thanks to Thijs Alkemade and Cornelius Aschermann for talking through some of the finer points of the protocol with me. And lastly I would also like to thank Sam Whited, Holger Weiss, and Florian Schmaus for their input on the standard.
+Big thanks to Daniel Gultsch for mentoring me during the development of this protocol. Thanks to Thijs Alkemade and Cornelius Aschermann for talking through some of the finer points of the protocol with me. And lastly I would also like to thank Sam Whited, Holger Weiss, and Florian Schmaus for their input on the standard.