X, the platform formerly known as Twitter, is introducing a feature it’s calling end-to-end encrypted chat, which it will refer to as Chat or XChat. On paper, it boasts that only you and your recipient can read the messages you send. That promise is riddled with holes in practice, thanks to the design choices behind this week’s launch — big enough that privacy experts say you should wait to use it for anything sensitive.
The company is promising full end-to-end encryption, but cryptographers who have been dissecting what’s available in the latest test version say it falls short of the industry standard by a significant margin. X seems to agree with many of the issues.
How X’s configuration betrays its own encryption
After you set up XChat, you’re prompted to create a PIN number, four digits long. That PIN encrypts your private key — the key that unscrambles your messages — which X then holds on its servers. That design is the first issue. Best practice advises storing private keys solely on user devices, not held by a company.
There are only 10,000 possible combinations in a four-digit PIN. While absoluteness can be a part of the security properties of a system, it isn’t something that you can point to as a way to achieve end-to-end encryption, for if that single key is out on the table in plaintext, except it is locked up in hardware security modules (HSMs) with strong rate limits and wrapped in a strong key-derivation function like Argon2 or scrypt, a motivated insider can brute force it. Security researcher Matthew Garrett raised this very issue, observing that if the infrastructure and controls aren’t rock-solid around server-side key storage and weak-entropy protection, it’s open season for abusers.
HSMs are designed to ensure it is far too costly and difficult to tamper with a device, even if it is owned by the company itself. If there are not credible assurances — and independent verification — that HSMs and strong norms can be used, the active storage of users’ decryption keys on the service is still a critical red flag.
No Verify, No Trust: the AITM Problem
X also acknowledges that a rogue insider —– or the service itself — might be able to intercept conversations. That’s essentially an adversary-in-the-middle (AITM) risk: If the platform can swap in another public key for your contact, it can quietly eavesdrop. As Garrett notes: if X gives you the public key of your partner then you really have no way to prove that X didn’t invent a replacement.
Contemporary encrypted messengers deal with this by providing user-verifiable safety numbers or QR codes, and increasingly with some version of key-transparency systems. WhatsApp is the most well-known messaging tool using the Signal Protocol by default with more than 2 billion users, offers safety-code verification, and implemented a key-transparency service to defend server-side key swaps. Apple has for high-risk users in iMessage a contact key verification. Without comparable validation, XChat requires users to trust the server — the precise vector of attack that end-to-end encryption is supposed to prevent.
Missing essentials: PFS, transparency, and audits
The current X construction does not have perfect forward secrecy (PFS), a fundamental property where every session — and frequently every message — receives a fresh ephemeral key. With PFS, even if one long term key is lost, no one will be able to decrypt past conversations. Without the PFS, a single critical exposure can open up huge swaths of history.
Openness is another gap. So far, no protocol details or code have been publicized. Signal’s protocol is well-documented as open source and has been put under years of scrutiny by academics and companies like NCC Group and Trail of Bits. Wire and Matrix (Olm/Megolm) release specs and pay for audits. Apple, meanwhile, published a doc about its upgrade to PQ3 to iMessage, getting it to post-quantum-hardened key exchange. X claims it intends to issue a whitepaper and open-source its work, but confidence in encryption comes through third-party analysis, not assurances.
And Matthew Green, a cryptography expert at Johns Hopkins University, has harbored similar concerns. His perspective is consistent with a widespread belief in the field: For as long as a design remains opaque and has not been independently scrutinized, users should presume flaws are present.
What to use now — and what X must do
You should use Signal if you rely on private messaging to stay safe or make a living. It’s open, has an audit and supports stuff like the Double Ratchet and a post-quantum hybrid handshake (PQXDH). WhatsApp’s default end-to-end encryption, using the same core protocol, is also strong, and for the most part, key verification options are available. iMessage provides valuable security in an environment utilizing Contact Key Verification, even for high-risk users.
If X wants to earn some trust, then they should release a full threat model and protocol spec, release open source clients/servers, add PFS and a neat UX for verification (safety numbers/QR); implement key transparency, secure keys behind HSMs with observable controls, remove that fucking 4 digit PIN and use a rich entropy passphrase with modern KDFs and aggressive rate limits, and order an independent audit from a reputable firm and a real meaningful vulnerability disclosure first-class citizens kind of bounty program. Until that happens, understand that XChat is experimental, not secure.
