Ask HN: Has anybody built search on top of Anna's Archive?
289 points by neonate 5d ago 146 comments
Ask HN: Is there any demand for Personal CV/Resume website?
6 points by usercvapp 1d ago 15 comments
A bit more on Twitter/X's new encrypted messaging
111 vishnuharidas 67 6/9/2025, 6:37:59 PM blog.cryptographyengineering.com ↗
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.
I definitely don't trust all of them, in particular the yappy one who was publicly inflammatory on Christmas Day. In a regular corporation there would have been public consequences. If it was overlooked here, what else and who else is being overlooked? It's the culture.
While I can't speak for Twitter's org as a whole(sorry anyone who works there), the fact that Elon encourages that racist troll to publicly post, as a known employee of the company, indicates to me the team is probably super immature and not to be trusted.
Well that's not a short list at X.
Nor should you or have to.
Twitter's new encrypted DMs aren't better than the old ones - https://news.ycombinator.com/item?id=44191591 - June 2025 (204 comments)
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.
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/
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.
This is a much much much better situation than handing someone your keys and letting them MITM you at any time with no hope of knowing.
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?
No comments yet
The worry people generally have about these sorts of systems isn't that they distrust the substrate NOW, as you say all bets are off at that point unless you're a cryptography expert and programmer yourself, but rather that they want protection of the data they produce now from being read in the future.
Basically, If twitter wanted to read my data today, they could do so. If they decided in 2 years to read my data now, it would be too late because it was encrypted. With the encryption key, that's trivial. If they have to save the plain text, well that's too late now.
Crichton claimed this effect was unique to popular newspapers - but actually I think today we can say it applies elsewhere, people will see that Musk hasn't the faintest idea how software engineering works and then go straight back to believing on aerospace.
With public/private key pairs, encrypting anything with the private key means that you use the public key to decrypt that same thing. This means anyone (as the key is public!) can decrypt the thing. So if you get the public key, and if the thing decrypts successfully, then you know that the corresponding private key was used to encrypt the thing. This is considered proof that the private key holder encrypted the thing / sent the message, and that's why everyone calls it "signing" instead of "encryption" - you send the cleartext thing along with the encrypted thing.
For private messages, you encrypt with someone's public key and have them decrypt with their private key. You'd sign it with your key, and that person would verify the signature with your key. That's 4 keys you need to worry about.
This doesn't even begin to consider key rotation, perfect forward secrecy, multiple recipients, etc.
Usually you want separate key pairs for signing/verification vs encryption/decryption, but some systems can safely share a key pair for these two sorts of operation.
No comments yet
Maybe I'm just being too generous to people suffering from the human condition. We should probably start holding everyone to the standard of absolute perfection all the time - never misspeaking, never making any typos - and start reflexively discarding any and all ideas that have any kind of minor mistake in them; that sounds like a much more rational and reasonable approach.
But for this claim in particular, there's another element that makes me think the claim was intended to be truthy instead of true. "Bitcoin style encryption" feels like it's meant to be a riff on "military-grade encryption"--a signifier that it's "really good" encryption while being extremely vague on what it is, but using "Bitcoin" instead of "military" to make him seem cooler to the people for whom cryptocurrency references gives you extra credibility.
Even if we assume it's a brain fart for "cryptosystem" or something similar... people with a basic understanding of cryptography recognize that bitcoin isn't using encryption, so a reference to Bitcoin's cryptosystem isn't directly relevant in the first place. To the extent Bitcoin itself uses a cryptosystem, it's the same cryptosystem everybody is using, so the reference itself degenerates "hey, we're using the same algorithms everybody does" which isn't something to tout.
So, no, I don't think it's a brainfart. I think it's a smarter-than-thou bullshitter trying to bullshit his audience, although I'm willing to accept that he may "just" be an idiot repeating what somebody told him without properly understanding what was told to him, leading him to give a confused response.
Even your corrected, generous version is wildly inaccurate.
Your post completely sailed right past that alternative plausible explanation, and immediately went back to asserting the unsubstantiated claim without addressing the alternative hypothesis, in what appears to be a bout of motivated reasoning against a figure that is politically disliked.
You don't get to completely ignore the point I'm raising, assert your own, and then play the "why aren't you staying on topic" card when your post was the one that brought up an unsubstantiated and unrelated response to the initial claim - that's hypocritical at best, if not outright trolling.
Other than me not making this claim at all, of course it’s substantiated, given he literally mixed up these terms people purporting that kind of expertise typically don’t. That’s literal substantiation, but whatever, I wasn’t even making that claim.
If it seems like I’m skipping past your point it’s because you’re not really making one, or at least not the clever one you seem to think you are.
To answer your q in good faith - yes, I have mixed up words, even in professional settings. I will then typically issue a correction, because the degree of such a mixup can cast a shadow on my credibility and can damage my career and thus earning potential. You seem to be taking the position that elon’s credibility cannot be questioned, at least on the topic of technical expertise. I find that a little bit (actually a lot) silly and an infantile way of looking at this.
Likewise, if I was routinely claiming to be this like, super technical genius founder engineer elite space dude that could never admit fault and was an expert at basically all topics, I would expect to be placed under the same skeptical lens (if not much more, given I’m just a low level grunt) I would face in a scenario like this in my day to day work.
Does this explanation help?
if you're one of the most powerful people on the planet and you make public statements and decisions that will impact many people, you should be held to a higher standard of emission.
It literally doesn't matter whether it's a mistake, he does this too often to give him the benefit of the doubt anymore. Elon Musk reliably claims to be an expert in everything ever, despite all available evidence to the contrary. Elon has never demonstrated technical competence in anything.
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.
To not even let users choose their own security tradeoffs with an optional longer passphrase seems very bad.
I think he has been off the ball with Twitter/X, using it as his own private megaphone rather than building out the features, however, encrypted messaging is going to be the cornerstone of future developments such as a means of payment, or a WhatsApp rival and so on. I find it hard to believe, but maybe there is a cadre of engineers at Twitter with a vision of what it should be, and building out a serious platform.
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.
So many products, printed packaging, websites, business cards, games, etc. had the Twitter logo and link on them. It was even integrated into iOS at one point.
This wasn't the first time either.. he tried it with PayPal as well, but they said no, we aren't doing X as the name for PayPal.
The boss can do what they want like all bosses, but this wasn't a decision based on fiduciary value for the shareholders.
Not sure it being open source is required to be considered "encryption". Besides, even if you can look at the code you don't know if that's what's running on the server.
" Klq prob fq ybfkd lmbk plrozb fp obnrfoba ql yb zlkpfaboba "bkzovmqflk". Ybpfabp, bsbk fc vlr zxk illh xq qeb zlab vlr alk'q hklt fc qexq'p texq'p orkkfkd lk qeb pbosbo."
I'm telling you that I applied state-of-the-art, uncrackable encryption to that. Why should you believe me? What evidence do you have that I didn't just take your text, throw it in some Caesar Cipher generator, and copy-paste it into this text box?
Well, none. It just happens to look like I did that, and if that were data you wanted to keep secret but that a hacker had obtained without permission, you can bet that they would say "looks like a Caesar Cipher, I'll try a combination of decryption parameters until it makes sense".
And in this case, they'd be absolutely correct.
That's why we have proper end-to-end encryption in the first place: So that you don't have to trust the server.
If the service doesn't let you do that, that's obviously a problem.
> 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.
When Trustico decided to light their whole business on fire they sent people's private keys to the root CA they were reselling, triggering all the relevant certificates to immediately get revoked.
But if you were like "LOL, use keys you picked instead of my own private keys I tell no-one? Do I look like moron?" then no matter how stupid, greedy or incompetent Trustico were they didn't have your keys and couldn't give them away on purpose/ accidentally.