> 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.

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.

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

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?

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/

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.