XChat launches standalone iOS app as security concerns remain

Almost immediately, security researchers raised fresh warnings about the platform’s encryption claims. The iOS developer and privacy-focused research duo Mysk published an analysis questioning whether XChat truly delivers end-to-end encryption as advertised. Their findings are based on network traffic inspection of the newly released iOS app.

According to Mysk, XChat relies on the Juicebox protocol to manage encryption keys, using a four-digit PIN as the primary mechanism for securing access. While the protocol is designed to split encryption keys across multiple “realms” to prevent any single point of compromise, Mysk observed that all of these realms are hosted under the x.com domain and controlled by X itself. This undermines the intended security model, as the same entity effectively holds all the key fragments.

The researchers also noted that the app does not implement certificate pinning, allowing them to intercept and decrypt its network traffic during testing. Based on this, they concluded that X could theoretically reconstruct users’ private keys and access their messages, contradicting the core promise of end-to-end encryption, which holds that only communicating users should have access to content.

XChat is part of X’s broader push to transform its platform into an all-in-one communication ecosystem. First introduced in 2025 as a replacement for legacy direct messages, the system supports encrypted one-on-one and group chats, file sharing, disappearing messages, and audio/video calls. It is built using a custom Rust-based protocol (Juicebox) layered on top of Libsodium cryptographic primitives, and notably does not require a phone number, positioning it as a competitor to apps like Signal and Telegram.

Despite these ambitions, concerns about XChat’s architecture are not new. Earlier analyses by cryptography experts, including Dr. Matthew Garrett, identified multiple weaknesses in the system. Chief among them is the reliance on a low-entropy four-digit PIN to protect private keys stored on X’s servers, making brute-force attacks feasible under certain conditions. Additionally, researchers have noted the lack of forward secrecy, meaning that if a key is compromised, past communications could also be decrypted.

Other gaps include the lack of independent key verification, opening the door to potential man-in-the-middle attacks, and no clear evidence that X uses hardware security modules or independent custodians for key management. While the Juicebox protocol theoretically supports distributed trust, current implementations appear to be centralized within X’s infrastructure.

Until X provides independent security audits, stronger key protection mechanisms, and verifiable separation of key custody, users requiring robust privacy are better served by mature platforms that implement proven end-to-end encryption models with forward secrecy and hardware-backed protections.