As a battle-tested protocol with a long history, XMPP remembers the era when encryption still was a luxury. Unlike some younger instant messaging protocols which were already designed with encryption in mind, XMPP, when it first appeared in 1999, was all about plain text. Which means no C2S (client-to-server) encryption, no S2S (server-to-server) encryption, and moreover, no any E2EE (end-to-end encryption). In fact, even though it's unrecommended by security guidelines, it's still possible to use XMPP in this pure, primordial form, so with a proper setup, you can still connect a long-abandoned XMPP client from early 00s, like TVJab for MacOS Classic, or SieJC for Nucleus OS on Siemens feature phones (do you even remember Siemens made cellphones? ;) ), to a modern XMPP server. And this compatibility level is amazing!

However, as the world changed, it became clearer and clearer that computer networks cannot rely on mere trust anymore. Numerous approaches for C2S, S2S and E2E encryption for XMPP evolved separately, and could be used in any combination (if at all). Especially several incompatible standards for C2S. And new ones keep emerging, like, in 2022 someone made a XEP draft for secure S2S connections over WebSockets! For the purpose of this article, let's focus on E2E encryption, as this is the most debatable topic regarding instant messengers in general and XMPP specifically nowadays (after all, TLS/SSL are so omnipresent and boring nowadays that different ways to apply them to XMPP are boring as well, right? ;) ). We also wouldn't touch encryption for audio/video calls this time, as it's a completely different story only slightly related to XMPP itself.

The history of E2E in XMPP

Despite how old XMPP is, PGP (Pretty Good Privacy), the pioneer of end-to-end encryption, was released back in 1991 already. And the events regarding bypassing and alleviating the US export restrictions, which led to creation of the OpenPGP standard, all predate XMPP too. Even though it was primarily used for encrypted e-mail at the time, some enthusiasts attempted to apply it to XMPP soon, as mentioned in XEP-0027 (now obsolete and replaced with XEP-0373). While OpenPGP has its benefits, some users might find it preferable, and even some modern XMPP clients like Gajim and Dino still completely support this option, it has remained niché and lost favour generally. While being revolutionary in 90s, nowadays OpenPGP is overly simplistic, and its huge concern is the lack of forward secrecy. All the message history is encrypted with the same key, which means that once the key is exposed or stolen, all the messages encrypted with it become compromised at once.

Some more sophisticated cryptography was needed, and it was not long in coming. In 2004, OTR (Off-the-Record) encryption appeared, to address the lack of forward secrecy and repudiability in PGP specifically. OTR was designed agnostic to the plaintext medium used. Its first reference implementation is a plugin for GAIM (soon renamed to Pidgin), which is a multi-protocol client, with a very suboptimal (as for nowadays) support for XMPP among many other IM protocols of the era (most defunct already: XMPP outlived them). Thus it didn't really discern the certain protocol being used.

Later it was discovered that OTR is still vulnerable to MitM attacks, and this is how OTRv2 with the Socialist Millionaire's Protocol (SMP) appeared: more on that later.

As 10s approached, many things changed. Users massively went mobile, and this signed a death sentence for the whole generation of desktop-oriented IMs, poorly suitable for still slow, unreliable and costly cellular data of the time. A new generation rushed into the market, revolutionizing the way users deal with instant messengers, and features users expect from them. Only a few IMs survived the revolution, and XMPP is among them: given its open and adaptive nature, it bridged the old and new generations. However, by this bridging, it nevertheless ran into an aging problem (more on that later too).

Meanwhile, the Snowden's revelations finally brought things that were already obvious for cypherpunks into the mass mind. End-to-end encryption finally turned from something believed to be needed only for paranoids and criminals into a feature expected from any communication tool by default. This E2EE revolution was undoubtedly led by Signal which came just in time in 2013. Its protocol was based on OTR at first, but soon accompanied the Double Ratchet Algorithm which improved forward secrecy and session renewal usability over pure OTR. This implementation was quickly picked up by popular proprietary messengers: WhatsApp, Viber, Google Messages, Facebook Messenger and even Skype (yup, it's still alive, surprise? it's sentenced to death anyway). Virtually everyone… but the blue one… The amount of messengers using the same E2EE technology is quite disturbing actually.

The Signal's Double Ratchet was also borrowed into two major open protocols soon. Into Olm/Megolm for Matrix which appeared right away, and since that competes with XMPP. And… into OMEMO for XMPP.

OMEMO swept over the XMPP community like an avalanche. Being developed for the Conversations mobile client first, it got incorporated into tens of other XMPP clients just in a few years. Fun fact: even though OMEMO got standardized as XEP-0384 (still experimental, by the way), which defines a generic urn:xmpp:omemo namespace, most of clients de-facto still use the Conversations' "proprietary" eu.siacs.conversations.axolotl namespace. And the latest OMEMO 2 spec seems to be supported by no one but Kaidan, and which is worse, Kaidan supports only OMEMO 2, thus being incompatible with other clients. Might we be the second to support it, after all?..

This sweep became controversial though. As omemo.top lists, developers of some clients just rejected to accept the new OMEMO reality, and decided to stay with OTR if with any E2EE at all. In particular, Coy.im explicitly decided to stay with OTR and believe in the bright future of OTRv4 (which is still in development). Meanwhile, Gajim developers proclaimed OTR outdated and removed it from the list of officially supported encryption plugins (we keep supporting it, by the way, so users of new Gajim versions can still use OTR).

Wait a minute… does the fact Signal's protocol derives from OTR, and OMEMO derives from Signal, clearly mean that OMEMO supersedes OTR?

The OTR vs. OMEMO controversy

As mentioned, the fact XMPP is such a long-lasting protocol, has led to a community which consists of several generations already. And these generations… don't quite match.

There's a cohort of users who remember XMPP back from 00s. When it was named Jabber (even though it was later agreed upon that XMPP is the protocol, including its proprietary applications like those in Google Chat or WhatsApp), and Jabber is an open federated network of XMPP servers). That time, XMPP was a desktop-first protocol. All major clients were intended for desktops. Even though some mobile clients already existed, like Bombus, Jimm, Talkonaut, or Nimbuzz, they rather served to accompany a desktop client while a user was on the move, than to act as a primary or only client. Multi-device support and message delivery was also a pain. Only in late 10s, with the advent of message carbons and MAM (Message Archive Management), XMPP finally became a somewhat reliable solution for personal messaging (multi-user chats were fine though, as they work differently). This audience is rather conservative, it stays with clients with classic desktop UI like Pidgin, Psi (and Psi+), Miranda, Mcabber, Tkabber, sometimes even old versions of Gajim. (Pure observations.) The development of those clients is being continued slowly, if at all.

Another cohort is more progressive, or just came to XMPP late. Nowadays, they are typically online from Conversations or some of its numerous forks 24/7. As mentioned before, Conversations de facto leads an XMPP revolution since mid-10s. They also prefer desktop clients which follow the behaviour of Conversations, like Dino, Gajim, or BeagleIM. They came up with the Modern XMPP project. They care about a modern set of must-have XEPs, while frowning upon some older featureful yet potentially insecure XEPs like XHTML-IM. And they don't like the word "Jabber".

(It does also seem that the first cohort is predominantly Russian and the second one is predominantly Western, centered around Germany/US. So we might just have another pointless format war, like PAL vs. SÉCAM, huh? Feel free to come up with precise unbiased stats if you can. It's clear though that jabber.ru is severely lacking in terms of modern XEPs support.)

And "coincidentally", those classic desktop clients are also the greatest at OTR support:

• The pidgin-otr plugin, as mentioned, has been the reference implementation since the very existence of OTR. It's kind of possible to use OMEMO in Pidgin as well with the lurch plugin, but the experience is quite suboptimal, as everything is driven by commands and there's no autodetection of OMEMO sessions.
• Psi/Psi+ have both implemented.
• Gajim: a plugin existed since 2008 and available in the Plugin Manager; was broken and no more updated there since Gajim 1.0.
• Adium has integrated OTR support, while OMEMO is possible to use with an (abandoned?) Xtra.

So, the conspiracy solved, it's all Russian hackers and drug dealers behind, and pure stubbornness? No, not that simple really.

Benefits of OTR

Remember Coy.im? In the thread mentioned on omemo.top there already are some links and arguments and criticism for OTR.

Even the Thunderbird's builtin XMPP client has gotten an OTR support (and no OMEMO) quite recently. (Yes, this monster contains a builtin IM.)

Why do people keep doing that, and no one comes for them to smack the OTR zombie rising from its grave with a shovel?

Well, one of the reasons is that Signal ripped off only the encryption part from OTR. It didn't inherit SMP. A 2022 research shows that Signal is in fact prone to MitM. OMEMO also didn't inherit SMP, and didn't replace SMP with any other kind of in-band verification. While both offer some means for out-of-band verification (fingerprints in OMEMO and safety numbers in Signal), and for marking a conversation as trusted, this approach doesn't cover a way the verification should be done, and comparing fingerprints is not something user-friendly really.

SMP provides a pretty simple concept: a question and an answer about some shared secret that both parties know. No need to agree on some other communication channel, and moreover, to meet in person. We have this question&answer form implemented in another.im too, by the way.

Also, worth reminding that OTR is protocol agnostic, which means it works beyond XMPP too. We know it for sure because someone requested to implement a raw mode for passing OTR messages intact in our Zhabogram transport. (This feature was later inherited by telegabber too.)

Secret chats: new is well forgotten old

Okay, now about the blue one. (Sorry if you can't see colours.) Entering the market the same year as Signal, they brought their own domestic encryption. Written by Durov personally. And they still stay with it, with little modifications.

Secret chats there seem quite deficient at the first glance, if compared to Signal's ones. While a lot of criticism is related to chats not being secret or otherwise E2E-encrypted by default, or to the desktop client still not supporting secret chats, there are also problems with secret chats themselves. The primary concern is that they belong only to one device, while secret chats in Signal can be synchronized between multiple devices. Is this definitely a concern though?

The audit of OMEMO by The Guardian Project, developers of Orbot, shows numerous issues regarding multi-device support (GSO-001 and GSO-003, in particular). This can be expanded to a broader issue: gaining access to one of devices compromises the messages regardless of how secure other devices are. While the impact might be not as massive as with compromising a PGP key (e.g., because some of the message history can be not encrypted for the compromised device), it's still huge. Olm in Matrix has went even further for that matter: while OMEMO maintains at least some forward secrecy, Olm allows a new device to ask existing encryption keys from other devices, which allows it to decrypt existing message history which was not initially encrypted for it, but also ruins forward secrecy entirely.

Signal protocol, OMEMO and Olm are all dedicated to encrypting all the messages in any circumstances. Which means that, they had to be designed with ease of use in mind, so users would not complain too much over IMs being highly paranoid like if their users are secret agents and have to maintain a high level of conspiracy and self-discipline.

None of this applies to Telegram's secret chats. And to OTR too! (So they're conceptually similar, hence the heading.) As the messages belong only to one device, a user can be sure that as long as they control it, the messages cannot leak anywhere. And deleting them on this device means deleting them completely. And as long as MitM is avoided, no one can eavesdrop by attaching another device to the session somehow or breaking into another devices which messages are encrypted for too.

Worth reminding that when Gajim officially had an OTR plugin, this plugin also effectively disabled message logging and informed the user about that. Adium has the same feature by a setting. (Feel free to inform if any of XMPP clients supporting OMEMO allow this for OMEMO-encrypted chats.) As the name suggests, Off-the-Record means no recording. The idea is that messaging is temporary, and should disappear forever as long as the session is closed. Just like it happens with verbal conversations: if no one (secretly?) recorded them, they remain only in memories of the speakers. Telegram also allows to close secret chats and to delete them from a device with ease.

Regarding XMPP, there's a usability problem which many OTR implementations (including plugins for Pidgin and Gajim, and Thunderbird's implementation too, at the very least) suffer from. If there are many devices (resources) online simultaneously, it's not clear with which one an OTR session should be initiated, and thus it's picked automatically which might not always be desirable. We have solved it in another.im: a user can pick a certain resource manually. Simple!

Future

It's hard to predict where this competition goes. While some users see OTR as something needed "only for compatibility with Pidgin" (as Pidgin users still rarely use Lurch), and many OMEMO fans actively push it as the only desirable E2EE standard for XMPP, seeing anything else as "deprecated" (just as some XMPP libraries in its golden era of late 00s treated any other protocols as "legacy"), it's also clear that there's some niché and future for modern OTR usage too.

We at Narayana believe: together rather than instead. Just as our homepage tells "What does businessman and grandmother have in common?", you also shouldn't choose a client which supports OTR or OMEMO better as another.im support both well.

More controversies are upcoming as well. OTRv4 is on the go. OMEMO 2 is on the go. MLS might be an utopia, but it also has a chance to finally start pushing OMEMO (and Olm the same time) away. It would be fun to see how OMEMO fans turn out to be stubborn conservatives this time ;) And as the XMPP world evolves, we evolve too. Stay tuned.

Tags: encryption, otr