However, cryptographic analysis of the newly adopted protocols reveals that the security measures are far from adequate. After reverse-engineering the X Android application, experts concluded that X Chat does not provide end-to-end encrypted messaging (E2EE). Furthermore, it would require “rather little” effort for a malicious server operator to read user messages.
End-to-end encryption is typically defined as a method where only the participating users can read the plaintext messages, offering protection even from the server operator or governments spying on private conversations.
The primary reason X Chat fails to meet this security standard is its stated vulnerability to man-in-the-middle (MITM) attacks. The documentation itself states explicitly that X Chat “do not offer protections against man-in-the-middle attacks”.
Server hijacks key distribution
The core vulnerability lies in how conversation keys are distributed and managed. The server controls the key distribution process, supplying both the participants’ public keys and the encrypted conversation keys.
This centralised control means the server can easily hijack the key distribution process and consequently read all messages in the conversation. For instance, when one user (Alice) attempts to start a conversation with another user (Bob), the server can intercept Alice’s request for Bob’s public key and instead provide a public key controlled by the server. Alice encrypts the initial conversation key using the server’s key and sends it back. The server then decrypts this key, generates a completely separate conversation key for Bob, and sends that new key to him. The server is then positioned to decrypt, read, and re-encrypt every single message exchanged between Alice and Bob.
The standard practice to prevent this MITM vulnerability is performing mutual verification, where participants compare public key fingerprints outside the application; X Chat lacks this vital protection. Users are always relying on the server.
Absence of key ratcheting
A second major issue is the implementation of long-term keys for encryption, resulting in a complete lack of Forward Secrecy and Post-Compromise Security.
Forward Secrecy ensures that if secrets are compromised at one point, past messages remain secure. Post-Compromise Security ensures that future messages become secure once the compromise is resolved.
X Chat encrypts messages using a shared secret called a conversation key. This key is generated when the conversation starts and basically never changes. If this conversation key is compromised at any time, all past and future messages in that conversation can be decrypted.
Adding to the risk, these static conversation keys can always be restored using the long-term identity keys of the participants. Therefore, managing to compromise the long-term identity keys of just one participant allows an attacker to decrypt every message that user has ever sent or received, and will ever send or receive in the future.
Modern secure messaging applications typically implement key ratcheting, ensuring conversation keys change frequently and cannot be derived from past or future keys. While the documentation mentions X is “working on mechanisms to allow private key rotation to offer some forward security in the future,”the current design is considered “quite underwhelming” given that competitors have included such features for years.
Short PINs and private protocol
Furthermore, the X Chat implementation compromises security for user experience by limiting authentication keys. Although the underlying Juicebox protocol supports long Personal Identification Numbers (PINs) for security, X Chat limits users to four-character PINs.
X Chat uses Juicebox, an open-source programme, for storing and recovering long-term keys, where the secret (combined private keys) is split into multiple shares stored across servers with Hardware Security Modules (HSMs). The security relies heavily on the correct setup of the HSMs and strict rate-limiting of retrieval attempts. If these measures are flawed, an attacker could brute-force the weak four-character PIN and recover the long-term secrets.
Finally, meaningful evaluation of security protocols is impossible unless the protocol is known. The only public documentation is a brief help centre article lacking technical detail, and although a white paper has been promised “someday,” the protocol remains opaque. This means users must either trust X or rely on researchers like Nepožitek who reverse-engineer the clients.
The critical combination of missing Forward Secrecy, explicit vulnerability to Man-in-the-Middle attacks, and reliance on weak authentication methods means that if an attacker successfully modifies the application code, a messier scenario in web applications, they would be able to access all past and future messages of the targeted user.