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.
Sunspark · 1h ago
Same, but not even for Musk.. just their employees in general.
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.
silisili · 1h ago
Same thought, probably the same person I'm thinking of.
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.
IshKebab · 47m ago
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.
schmichael · 21m ago
Pushing a malicious app update creates an inspectable artifact. Researchers can discover exactly when it happened and therefore who is vulnerable and which messages.
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.
jonathanstrange · 14m ago
IANAL but the difference seems to be gigantic. If the secret key is stored on a company server, then that company can be subpoenaed for it. If it's not on the company's server, the client's endpoint has to be compromised (e.g. by a police raid or by electronic surveillance). The former is much easier than the latter. I don't think government authorities can force companies to actively eavesdrop on their clients by pushing malware through their update mechanism to a client's device, at least not officially in non-authoritarian countries with due process.
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.
The nice thing about these protocols is that you can add a memory-hard hash function like scrypt or Argon2 into the middle of the protocol. This is computed on the client’s side, and will “harden” the key derivation by a bunch: essentially slowing down brute-force attacks by as much as the hash function costs. As best I can tell if you combine this with a very strong password, the problems I mention in the post won’t bother you (but no guarantees.) Unfortunately this still probably won’t save most users who choose short PINs and weak passwords, because offline password guessing is embarrassingly parallel and there’s only so much scrypt you can throw at any real system before everything becomes unusable.
bink · 1h ago
If the server is compromised then the attacker can probably just grab a copy of the private key when it's decrypted for use.
nine_k · 44m ago
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.
lxgr · 1h ago
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.
michaelt · 2h ago
> 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?
Calavar · 2h ago
I think the relevant scenario here isn't one where Twitter itself is malicious, but one where Twitter gets a law enforcement order requiring it to hand over decryption keys. If you don't have decryption keys, you can't hand them over.
No comments yet
delusional · 1h ago
> OK, so Twitter themselves are our adversary.
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.
echoangle · 36m ago
But as long as they can still get you (or the person you’re communicating with) to log in, they can still get the encrypted data in two years.
UltraSane · 2h ago
The one that Musk tweeted has "bitcoin style encryption" even though bitcoin doesn't use any encryption.
SAI_Peregrinus · 2h ago
It's at least as good as Bitcoin's encryption, so Musk's tweet is technically accurate.
blueflow · 2h ago
I guess that encrypting a hash with ECDSA (= to generate a signature) does not count as encryption?
Benanov · 58m ago
Correct.
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.
SAI_Peregrinus · 2h ago
That's signing, it's not encryption. It's a private-key operation, so at best you could consider it decryption. In asymmetric cryptography, the private keys are used for decryption & signing, and the public keys are used for encryption & verification.
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.
UltraSane · 2h ago
No, that is called signing and is not encryption.
No comments yet
vvpan · 2h ago
When Musk tweets on technical topics one can tell that either he's just trying to fool people or is completely clueless himself.
tialaramex · 1h ago
Gell-Mann amnesia effect applies - if you speak confidently about a topic where I know better I should judge your false confidence for other topics on which I know no more than you, because you're probably bullshitting just as much.
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.
anonym29 · 1h ago
I felt it was pretty probable that in his head, he was thinking "bitcoin style cryptography", which makes his claims much more technically accurate (even if the implementation ultimately ends up effectively handing over control of private keys to the service provider), and that he likely just had a brain fart in translating the idea from his head into written language, a common phenomenon that affects pretty much everyone at some point in time.
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.
jcranmer · 51m ago
It is possible that he had a brain fart. But Musk makes a lot of statements, and he's repeatedly demonstrated that he is the kind of person who wants to project an image of himself that is smarter than he is. There's a trend of people discovering, when he starts speaking in the areas that he's knowledgeable, that he's just a complete idiot making n00b mistakes in their field, and if he's that bad in their area, why not others? Recent entries in this category include programming and playing Diablo, but the conversion factor for me was hearing him talk about tunneling and transit technology. And once you hear him as a fast-talking technobullshitter, it's hard not to treat any future misstatement of him as anything but fast-talking technobullshittery.
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.
JohnMakin · 1h ago
Except Musk and the chadsphere he surrounds himself with spends an inordinate amount of time promoting him as some kind of techno-genius. A first year CS student couldn't confuse those terms, and he makes embarrassing gaffes like that quite often. They go ignored because people make unlimited amounts of excuses for him for some reason, other than the very obvious conclusion - that he doesn't know wtf he is talking about.
Even your corrected, generous version is wildly inaccurate.
anonym29 · 1h ago
There hasn't ever been a single time in your entire life where you were thinking of one thing, but the words coming out of your mouth communicated something different, by mistake, even though you genuinely did understand the difference?
vel0city · 4m ago
How many times do you make that excuse of "he just flubbed a word" before thinking maybe he doesn't really know what he's talking about? Once? Twice? A dozen times?
mrguyorama · 33m ago
If you don't want extra skepticism, don't be the richest person on earth, don't insert yourself into government, don't insist you are uber-intelligent, don't be a notable person, don't be an asshole in public, etc.
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.
JohnMakin · 1h ago
Do you understand the post you are replying to? If you do, what does this question have to do with it?
anonym29 · 57m ago
I do, but that post is arguing a point (Elon Musk doesn't know the difference between encryption and cryptography) that's unsubstantiated, while a plausible alternative explanation (he does know the difference, and mis-spoke, because he, like all other human beings, sometimes makes errors in translating thoughts into words) was proposed in my parent post.
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.
GuinansEyebrows · 16m ago
the point is less the infallibility of human cognition and more Spider Man's Law (with great power comes great responsibility).
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.
tdeck · 3h ago
Who is this for in the first place?
qualeed · 2h ago
For Twitter/X users that want to communicate with each other using end-to-end encryption.
dpkirchner · 2h ago
Where "end" is a bit loose -- presumably nothing stopping them from reading the text when it is rendered in a div or what have you.
Theodores · 1h ago
Musk considers Twitter as the 'town square' and he wants to bring all of those features for payment and whatnot that apps in China already have to his 'town square'.
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.
wdb · 2h ago
Pretty sure this problem has been resolved many decades ago.
hbn · 3h ago
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.
CobrastanJorji · 2h ago
It's X, the company that took the brand "Twitter," valued at multiple billion dollars, and changed it to X because its owner thought X was a pretty cool name, and did it without telling any of the UI designers in advance.
hbn · 56m ago
The weird thing is the dedicated Grok app is actually quite pretty/fluid
Sunspark · 1h ago
I'm still stunned by that.. definitely a Joker lighting the money on fire scene.
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.
Benanov · 57m ago
Seeing such weaknesses and poor execution generally means that a lot of talented folk are choosing not to work at that company.
stefan_ · 2h ago
Is anyone still clicking on that? It's just a billion group chat spam messages and grifter message requests.
lenerdenator · 3h ago
If you can't look at the code doing the encrypting, it's simply encoded.
barbazoo · 3h ago
> If you can't look at the code doing the encrypting, it's simply encoded.
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.
lenerdenator · 1h ago
Of course it's a requirement to be considered encryption. Let's take this "encrypted" copy of the text in your reply:
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.
robmccoll · 3h ago
If I can look at the code, decide I trust the implementations of the primitives being used, how they're being used, how identity is established, and how initial key exchange works, I don't need to know what's running on the server. That's sort of the point of end to end encryption.
barbazoo · 3h ago
You mean using the algorithm to verify that the observable input leads to the observable output? That would make sense and would allow you to form an opinion about the "primitives" like you said.
csallen · 2h ago
I think they meant client
SV_BubbleTime · 3h ago
I gave a charitable reading to that comment as “in terms of trust”.
lxgr · 1h ago
If you don't trust whoever is handling your server-side secret computation, being able to view the code supposedly running there doesn't help either, as you won't have proof that that's what they're actually running.
That's why we have proper end-to-end encryption in the first place: So that you don't have to trust the server.
lenerdenator · 1h ago
How do you know that the server is being handed encrypted content?
lxgr · 1h ago
Hopefully via running your own client and seeing that the math still works out.
If the service doesn't let you do that, that's obviously a problem.
nimbius · 3h ago
> 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.
Dwedit · 3h ago
"Not your keys, not your crypto" - Not just for cryptocurrencies anymore.
tialaramex · 1h ago
It's always been true for all cryptosystems.
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.
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.
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.
Twitter's new encrypted DMs aren't better than the old ones - https://news.ycombinator.com/item?id=44191591 - June 2025 (204 comments)
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/
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.
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.
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.
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
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.
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.
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.
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.
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.
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.