Elon Musk’s long-teased encrypted messaging platform, XChat, is rolling out this week, featuring vanishing messages, support for any file type, and audio/video calling, all without requiring a phone number.
Built using Rust and “Bitcoin-style” encryption, the platform is a major architectural overhaul for messaging on X. However, early evaluations from cryptography experts raise concerns about the robustness of its security claims.
The announcement was made via Musk’s personal account on June 1st, 2025, where he outlined core features including end-to-end encryption and a PIN-secured private key system based on a new protocol called Juicebox. Musk also noted that XChat enables platform-independent audio and video communication without a phone number, targeting flexibility rivaling apps like Signal and Telegram.
While the technical pivot to modern cryptographic libraries, specifically Libsodium's box primitives, marks progress over X’s earlier flawed attempts at secure messaging, researchers say the execution leaves users vulnerable to metadata leakage, key interception, and brute-force attacks. One of the most comprehensive early assessments comes from Dr. Matthew Garrett, a well-respected open-source security expert and kernel developer, who evaluated XChat’s cryptographic architecture in detail.
XChat not ready for prime time
According to Garrett, although XChat now uses more abstracted cryptographic components and implements them with support from the Juicebox protocol (written in Rust), several serious weaknesses remain. The platform's encryption model relies on the secure storage of users' private keys, which are encrypted using a four-digit PIN and protected by the Argon2id key derivation function. While Argon2id is a modern and memory-hard function, Garrett’s testing showed that the current parameters allow a modest attacker with a small number of machines to brute-force the PIN in a matter of minutes.
More critically, the centralized key management system remains under Twitter/X's control, relying entirely on its backends hosted under the x.com domain. While Juicebox theoretically supports multi-party sharding, Garrett found no evidence that XChat is using independent or third-party key custodians. This means the server, or any actor controlling it, could potentially extract private keys if compelled or compromised.
Another red flag discovered in the evaluation is the absence of forward secrecy. This means that if a user’s private key is ever compromised, all previously sent messages could also be decrypted — something widely considered a baseline security feature in modern encrypted messengers like Signal, which has offered forward secrecy for over a decade. Additionally, the system lacks authenticity guarantees for recipient public keys. Since there’s no out-of-band verification, X’s servers could perform a man-in-the-middle (MITM) attack by substituting a key under their control to intercept and re-encrypt messages.
Despite these technical limitations, XChat does benefit from better scalability compared to its previous encrypted DMs, and the use of Rust in parts of the implementation does help reduce certain classes of memory safety vulnerabilities. However, Garrett points out that the encryption core, Libsodium, is still the C version, used via JNI bindings, raising questions about how thoroughly Rust’s safety guarantees apply across the codebase.
Ultimately, while XChat may represent a meaningful step forward for messaging on the X platform, it falls significantly short of industry-leading privacy tools. Until X commits to open audits, verifiable key management, and stronger PIN protection, or better yet, deploys hardware-based security modules like Intel SGX as Signal does, users seeking robust privacy are advised to rely on mature, independently audited applications.
Leave a Reply