from Hacker News

A bit more on Twitter/X's new encrypted messaging

by vishnuharidas on 6/9/25, 6:37 PM with 79 comments

• by dang on 6/9/25, 7:09 PM

  Recent and related:

  Twitter's new encrypted DMs aren't better than the old ones - https://news.ycombinator.com/item?id=44191591 - June 2025 (204 comments)

• by IshKebab on 6/9/25, 9:22 PM

  IMO the difference is mostly theoretical anyway. Despite the fancy HSMs and end-to-end encryption, if Signal or Whatsapp wanted to read your messages they trivially could - just push an app update to you that sends all of your messages to them.

  It's more risky in terms of getting caught, but probably not hugely so if you do it in a way that has plausible deniability.

  I think you pretty much have to trust the app supplier. Which in this case, I do not.

• by BHSPitMonkey on 6/9/25, 10:47 PM

  As a former user of XChat the IRC client (http://xchat.org/), this rebrand makes me sad.

• by UltraSane on 6/9/25, 7:14 PM

  The one that Musk tweeted has "bitcoin style encryption" even though bitcoin doesn't use any encryption.

• by michaelt on 6/9/25, 7:51 PM

  > The obvious remedy for this problem is just to store secret keys with the service provider itself. This is convenient, but completely misses the whole point of end-to-end encryption, which is that service providers should not have access to your secrets! Storing decryption keys — in an accessible form — on the provider’s servers is absolutely a no-go.

  OK, so Twitter themselves are our adversary.

  > One way out of this conundrum is for the user to encrypt their secret key, then upload the encrypted value to the service provider. [...] Most human-selected passwords and PINs make for terrible cryptographic keys. [...] you need some mechanism to limit the number of guessing attempts that the user makes, so an attacker can’t simply run an online attack to work through the PIN-space.

  As I understand it, this stuff is all implemented in-browser, using javascript that's 100% under Twitter's control.

  Wouldn't it be a simple matter for them to save your message's plaintext (or indeed your password) by just saving a copy while it's in plaintext form?

• by Leo-thorne on 6/10/25, 2:52 AM

  I tried X's encrypted chat last week just to see what it was like. The interface is clean and it works smoothly, but once I understood how it actually handles encryption, I stopped using it. If they hold the private keys and there’s no forward secrecy, it makes me cautious. It feels more like something that looks secure rather than true end-to-end encryption.

• by lxgr on 6/9/25, 8:40 PM

  So is this protocol (Juicebox) at least safe when used with a high-entropy PIN/passphrase then?

  What's nice about Meta's similar implementation for chat backup using OPAQUE is that, given a high-entropy passphrase, the reliance on the server/HSM as a trusted actor goes away.

• by wdb on 6/9/25, 7:19 PM

  Pretty sure this problem has been resolved many decades ago.

• by tdeck on 6/9/25, 7:07 PM

  Who is this for in the first place?

• by afavour on 6/9/25, 8:14 PM

  > User private keys are stored at X

  And I'm out. I don't want every thread about X to degenerate into another debate about Musk but at this point they're kind of inseparable. Do I trust that if Musk decided some day that he doesn't like me for whatever reason that he wouldn't grab that private key and publish my DMs? I can't.

• by hbn on 6/9/25, 7:02 PM

  The UI around it is so nonsensical too.

  It's a tab in the drawer called "Chat", I guess to distinguish itself from the legacy "Messages"

  But then you click the Chat button and it takes you to a screen called "Messages" that looks visually identical to the old Messages screen. Furthermore, the Chat button icon is a message bubble, as to not be confused with the envelope icon for Messages. But the compose button in the Chat screen is the envelope with a +, and clicking it brings you to a screen titled "New message". The compose field in the chats themselves is also labelled "Message".

  This is like the most basic shit to get right.

• by afarah1 on 6/9/25, 7:54 PM

  The author writes that the encrypted private key (DEK) is susceptible to decryption if the server is compromised because then there are no more limits on incorrect attempts, allowing an attacker to walk the whole key space (of the KEK). But doesn't strong password requirements and a proper derivation function provide a large enough key space, making decryption by guessing (through any of various methods) infeasible?

  The author only mentions two alternatives for this problem, hardware security modules to prevent the compromise of the DEK from the server in the first place, or "sharding" between independent hosts to minimize the odds of that. Both certainly harden the server, but what about hardening the KEK?

  The author mentions PINs for the KEK because they are easy to memorize, which certainly makes for a poor key space, but why not use the same password the user already memorized to login, which should have strong requirements? Proton Mail, which also stores user's (encrypted) private keys,[1] initially had two passwords, one for login and one for decryption, and now allows users to have a single one, used both for login and decryption but never transmitted to the server, by using SRP for authentication.[2] Yet another approach is taken by Mozilla for Firefox Sync, which does two key-derivations on your password at your machine, creating one key for authentication and a separate one for decryption.[3] I wrote more about both approaches, check my submission history if you're interested.

  Anyway a nice read, I just missed more discussion about hardening the key in the first place, and how far that gets you in case of server compromise.

  [1] https://proton.me/support/how-is-the-private-key-stored [2] http://srp.stanford.edu/ndss.html [3] https://hacks.mozilla.org/2018/11/firefox-sync-privacy/

• by nine_k on 6/9/25, 9:25 PM

  I find this all moot. Not useless (because it's another layer of defence in depth), but still recoverable.

  A real end-to-end encryption is such that the transport intermediary only passes opaque blobs, and won't be able to decrypt them to save the CEO's life. Everything else is sparkling obfuscation.

  But even with that level of unbreakable content encryption, the metadata, which has to be accessible to the intermediary in cleartext, could blow enough covers.

• by lenerdenator on 6/9/25, 6:48 PM

  If you can't look at the code doing the encrypting, it's simply encoded.

• by nimbius on 6/9/25, 6:49 PM

  > There’s no forward secrecy.

  > User private keys are stored at X.

  things i would commonly give a pass for major companies were they not under the immediate control of Elon Musk.