What are possible implementations of the XMPP protocol

Conversations: Messaging via the XMPP protocol - Messenger part 6


The Messenger Conversations has been developed by Daniel Gultsch exclusively for the Android world since the beginning of 2014. As of September 2020, the Messenger had over 100,000 installations via the Google Play Store (€ 2.29). Current user numbers are difficult to estimate, however, as many users obtain conversations from the privacy-friendly F-Droid Store.

In contrast to many other messengers, Conversations does not have its own protocol for exchanging messages, but is based on the Extensible Messaging and Presence Protocol (XMPP). XMPP is a veteran whose beginnings go back to 1998 and was developed as a (communication) protocol for the exchange of information and data.

Conversations and the XMPP world allow people to interact with one another or to operate a communication network without being dependent in any way on central providers. Especially for people or institutions with a high Need for autonomy this should be a big plus.

This post is part of a series of articles:

2. Encryption | Cryptography

To ensure "tap-proof" communication, Conversations relies on end-to-end encryption (E2EE) of the message content. For this purpose, the messenger uses the XMPP extension OMEMO (alternative OpenPGP), which is based on the double ratchet algorithm and PEP (XEP-0163). Double Ratchet was originally developed for the Messenger Signal, but was then adapted by other messengers (e.g. Wire) and adapted to its own environment. Like the Signal Protocol, OMEMO supports credible deniability and lack of consequences (Perfect Forward Secrecy (PFS)).

If all participants use conversations, the communication content (messages, files, etc.) is E2E encrypted by default - both in individual and private group chats. Public group chats are an exception. However, users of conversations should not assume that communication with a chat partner is always initiated by E2EE as standard or that it is even possible in encrypted form. In the XMPP world, Conversations is just one of many clients that enables (encrypted) communication between the participants. Ultimately, it depends on various factors whether E2EE communication can take place - if an XMPP client supports OMEMO, an important foundation stone has already been laid. Due to the Fragmentation In the XMPP world, users must always pay attention to whether the communication is E2EE or, if possible, unencrypted. In addition to the problem of fragmentation, there are other disadvantages that can have a negative effect on confidential communication:

  • iOS: Unfortunately there is no XMPP client for the iOS world with which a complete and error-free exchange of messages in MUCs (private or public group chats) via OMEMO is possible. Apart from that, there is an OMEMO-capable client for almost every system.
  • OMEMO: At the moment, the OMEMO implementation for MUCs can generally be described as problematic (Issue # 3262, Issue # 3081) and some even generally view OMEMO as critical: Future of OMEMO.

To be fair, it must be said that the cause of the problems identified have little to do with conversations themselves, but mainly with the openness and slow development of XMPP. In contrast to closed (messenger) systems, the further development of an open standard requires significantly more manpower and time - which, however, is difficult to cope with due to the chronic underfunding.

2.1 Authentication

Those who do not authenticate their counterparts can never really be sure whether they are actually exchanging messages with the desired communication partner or possibly with an unknown third party. For this purpose, Conversations offers authentication based on a fingerprint (character string):

The lock symbol shows whether the received message has been encrypted. Before you type something, you also get visual feedback as to whether the message is sent OMEMO-encrypted.

3. Central | Federated | Decentralized

In contrast to most messengers, communication or the exchange of messages does not take place via central servers. In order to be able to chat with someone, an XMPP account must be available on a server or a new one must be created. You can think of an XMPP account as a kind of email address that is assigned once. As with an email provider, you first need a new (XMPP) account with a provider of your choice.

The user is therefore completely free to decide which XMPP server or provider to open an account with in order to then use it with any XMPP client. In contrast to a centralized service such as WhatsApp, Telegram and Co., it is not one provider alone that determines the rules of the game. The architecture or the principle of the federation pursues one open Collective networking approach where nobody is excluded.

For beginners, entry into the XMPP world takes a bit of getting used to - this is particularly due to the distributed server infrastructure (federation) as we know it from the e-mail world. There are excellent instructions to help you get started with Conversations / XMPP. A little more detailed: The Conversations Compendium.

4. Metadata

One of the greatest strengths of XMPP is also its greatest weakness: the federality. Once an XMPP server federates with others, it is part of a bigger whole. Unfortunately, some XMPP servers are not operated with the care and responsibility that should be taken for granted with federated protocols. In practice, problems such as loss of messages or failed connections occur time and again because a number of servers are out of date and, for example, do not support the latest OpenSSL cipher suites.

Overall, this is annoying, but it can be made up for by choosing a reliable and savvy server operator. The real problem lies elsewhere: XMPP itself. The protocol is historical and was originally not developed with a focus on avoiding or protecting metadata. This is noticeable in various places:

  • Server log files: An XMPP server admin theoretically has access to a lot of (sensitive) metadata via the log files or the server-side database. The potential for abuse can be classified as high:
    • Reading out the login password used for your XMPP account
    • Access to the list of saved contacts / vCards
    • Access to cached offline messages (if stored unencrypted, can also be viewed)
    • Access to the archive or the message history
    • View of all currently connected users including IP address, port, etc.
    • View all group chats or MUCs including the MUC options and members (admin, moderator, participant)
    • […]
  • Server security: The OMEMO protocol enables end-to-end encryption, so that no one except the participants in a discussion can read the content. However, viewed on its own, the OMEMO protocol is far from being a coherent security concept, but just a piece of the puzzle. Particularly on the XMPP server side, the operator must ensure that the server is well protected against attacks so that the (meta) data of the users is not fished without authorization:
    • Hardening of the system or reduction to the essentials
    • Regular installation of (security) updates
    • Use of current OpenSSL libraries
    • Use of valid TLS certificates (e.g. Let's Encrypt)
    • Force encrypted connections between the XMPP servers

Avoiding metadata is accordingly no Strength of XMPP and therefore not of conversations. OMEMO can protect the participants from reading the content data (or messages) - at the end, however, some metadata (e.g. contact list) and the possibility of accessing your password remain. So it takes a lot of trust when you create an account on an XMPP server. Apart from the collection and storage of this metadata, an XMPP server admin can at least restrict the data collection via certain server parameters. By minimizing logging, it is possible, for example, to discard the IP address, the time of registration or use of the XMPP server. However, this is not verifiable.

By registering an XMPP account, a user inevitably enters into a close relationship of trust with the server admin or operator. If you do not want this for the reasons mentioned above, you have the option of running your own XMPP server, for example on the basis of Prosody or ejabberd - however, this is not a "walk in the park", as the article "ejabberd: Installation and Operation" of an XMPP server «.

5. Identifier

Conversations uses an XMPP ID as an identifier, the structure of which is similar to an e-mail address. My XMPP ID or address is, for example:

[email protected]

The first part is my chosen nickname of the account that is on the XMPP server.

By default, Conversations does not transmit address book data (such as telephone numbers) to external servers, as is the case, for example, with messengers such as WhatsApp and Co. In contrast to many other messengers, Conversations enables an identifier that Not is tied to the phone number. Conversations optionally offers address book integration.


The conversation offshoot Quicksy is also being developed by Daniel Gultsch. In contrast to Conversations, Quicksy offers the option of choosing the telephone number as the user name. This is intended to enable other XMPP users to search for contacts via the app or the phone book and, overall, to reduce the hurdle to enter the XMPP world.

6. Open source | transparency

The source code of Conversations is open (GPLv3 license) and can therefore be viewed by everyone. As a result, an independent security check is basically possible. This openness is an essential step towards more transparency the application and thus ensures trust.

The last security audit by OMEMO (and Conversations) dates back to 2016, when some vulnerabilities were uncovered. Probably the biggest blunder is the vulnerability to a man-in-the-middle attack, since the OMEMO protocol does not provide for any authentication of the messages:

One cannot expect messages to remain confidential when one of the participating devices is malicious. However, a user might suspect at least that the integrity of messages sent by an honest device is guaranteed by the protocol. After all, a secure signal session with that honest device has been set up. However, the signal session only protects the random key. A malicious device has access to that key and can thus re-encrypt and re-authenticate any payload with that key, without the receiving party being able to detect it. This is illustrated in Figure 3. The displayed attack only shows the attack in one direction: Eve is able to modify and read anything sent by Alice. Eve needs to apply the same attack to Bob in order to setup up a bidirectional man in the middle attack. Note that Eve needs to strip of her own element from the list of keys in every message in order to remain undetected from Bob.

Two careful users will not be susceptible to this attack, because neither of them will ever accept an unvalidated key. However, no matter how careful Bob is with validating the identity key of the sending device, he must assume that Alice has never made a mistake and none of the devices were compromised in order to be guaranteed the authenticity of messages that come from any of her devices. This trust in the other party is not necessary, if the messages were authenticated inside the signal session. Also, Bob could make it less likely for Alice to accept a malicious device by creating a cryptographic link between devices.

In general, it should be remembered that such audits are always version-bound and have to be carried out again for new versions. This means that the audit cannot derive any information about the security level of the systems / software tested for the future - but this is a general problem that generally affects audits. Due to the ongoing development of conversations and also OMEMO and other XEPs, a new audit would certainly make sense.

7. Interesting facts

A few points worth knowing that Conversations offers are summarized below:

  • Multiclient: Users can synchronize their chats over several devices (multiclient), since XMPP is generally multiclient-capable. For the desktop, corresponding XMPP clients are available with Gajim (Windows, macOS and GNU / Linux) or Dino (GNU / Linux).
  • Without Google addiction: Via F-Droid, Conversations can be obtained completely separately from the Google Play Store. But that's not all: It works completely without proprietary Google libraries or Firebase Cloud Messaging. By default, the client establishes a (permanent) TCP connection to the XMPP server, which is maintained for about 5 minutes even if there is a network change (WLAN, mobile) or connection problems. Instead of always initiating a new connection, Conversations establishes a TCP connection, which is then used over a longer period of time for sending and receiving messages or push messages.
  • Voice and video calls: Conversations also offers the option of making encrypted voice or video calls with a contact. The transmission takes place via WebRTC and is protected with DTLS and SRTP.
  • OpenStreetMap: Your own location can be shared within the app and can then be viewed by the participants via the OpenStreetMap map material.

8. Conversations: advantages and disadvantages at a glance


  • The client is open source and the source code can therefore be viewed
  • Several devices can share an XMPP account - this can also be used, for example, to chat on the desktop
  • By default, end-to-end encryption is active for chats and private group chats (if the participants use conversations)
  • Conversations can be used without linking a telephone number - the identifier is the XMPP ID
  • Can also be used on google-free smartphones
  • Does not use the Google infrastructure for push notification
  • No (user) tracker integrated - transmission of crash reports is optional
  • Encrypted voice and video calls possible
  • Local backups possible - unfortunately not protected by encryption
  • No central server, but federal infrastructure


  • XMPP substructure is not designed to prevent or protect metadata
  • Fragmentation in the XMPP world often creates problems that can negatively impact security and privacy
  • The last security audit (2016) was years ago
  • Data protection declaration extremely concise and only available in English
  • XMPP's multi-client support can endanger the security of communication if handled incorrectly (e.g. failure to verify the device)

9. Conclusion

If you view conversations as an island of your own, then you could feel comfortable there and communicate “safely” with the other participants. However, as soon as more island states (other XMPP clients and servers) are added, the patchwork quilt that the XMPP world is struggling with becomes visible. The effects can be:

  • no standard initiation of end-to-end encrypted communication
  • (Private) group chats that do not allow encryption based on OMEMO because a client has not implemented the protocol or has only implemented it incompletely
  • Undermining security, as OMEMO's concept of multi-client verification has conceptual weaknesses
  • […]

In addition to fragmentation, this is necessary trust, that users have to bring to an XMPP server operator, probably the biggest toad to swallow. Originally, XMPP was not developed with the aim of protecting the metadata that arise during use and communication from curious operators or of preventing them from accumulating in the first place. Many XMPP users rightly perceive this downer as a bitter aftertaste.

Apart from that - or viewed in isolation from the XMPP world - Conversations is a rock-solid messenger that has been steadily improved over the years and expanded with new functions (most recently audio and video calls). It was Daniel Gultsch's tireless commitment that led to the development of OMEMO and other XEP extensions that shape the XMPP world today. Despite the weaknesses and problems identified, which can be traced back to the XMPP world in particular, I consider Conversations overall to be a great messenger that should appeal to users who have a high need for autonomy. Compared to other messengers, the combination of your own XMPP server and conversations should be a solution that allows the greatest possible freedom and independence.

Tl; dr: XMPP (and with it Conversations) was and is not the savior for the messenger world.However, XMPP is a solution that allows people to interact with one another or to operate a communication network without being dependent in any way on central providers. Nevertheless, one should be aware of the weaknesses of XMPP.

Conversations: Messaging via the XMPP protocol - Messenger part6 December 8th, 2020Mike Kuketz

Spread the word | Support

If you liked the post, then share him with your friends, acquaintances and fellow human beings. Use social networks, forums, emails or simply the next celebration / event. You are also welcome to support my work!

About the author

My name is Mike Kuketz and I am writing this blog to security- and data protection relevant Making topics easier to understand and accessible to everyone.

In my freelance work as Pentester (Kuketz IT-Security) I slip into the role of a »hacker« and look for weak points in IT systems, web applications and apps. Furthermore, I am Lecturer for IT security at the dual university in Karlsruhe and among other things as an author for the computer magazine c’t.

The Kuketz blog or my person is regularly represented in the media (heise online, Süddeutsche Zeitung, etc.).

Learn more ➡

If you want to be informed about the latest posts, you have several options to follow the blog:

Stay up to date ➡