5 ms·

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

129 points by vishnuharidas 1y ago

lenerdenator 1y ago
If you can't look at the code doing the encrypting, it's simply encoded.
- deleted 1y ago
  [deleted]
- barbazoo 1y 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.
  - SV_BubbleTime 1y ago
    I gave a charitable reading to that comment as “in terms of trust”.
  - robmccoll 1y 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 1y 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.
    - deleted 1y ago
      [deleted]
    - csallen 1y ago
      I think they meant client
  - lenerdenator 1y ago
    Of course it's a requirement to be considered encryption. Let's take this "encrypted" copy of the text in your reply: " 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.
- lxgr 1y 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 1y ago
    How do you know that the server is being handed encrypted content?
    - lxgr 1y 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.
      - lenerdenator 1y ago
        Does Xitter let you do that with the new feature?
nimbius 1y 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 1y ago
  "Not your keys, not your crypto" - Not just for cryptocurrencies anymore.
  - tialaramex 1y 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.
Kapura 1y ago
[flagged]
hbn 1y 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.
- stefan_ 1y ago
  Is anyone still clicking on that? It's just a billion group chat spam messages and grifter message requests.
- deleted 1y ago
  [deleted]
- CobrastanJorji 1y 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.
  - Sunspark 1y 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.
    - CobrastanJorji 1y ago
      And also SpaceX, of course. And the Tesla model X (as part of a series so he could have the models S, E, and X). And his son X. Well, X Æ A-12, but X for short. I hope that if I ever go crazy, there's someone who loves me that I trust that's around me to tell me when something I thing is cool is actually incredibly stupid.
tdeck 1y ago
Who is this for in the first place?
- qualeed 1y ago
  For Twitter/X users that want to communicate with each other using end-to-end encryption.
  - dpkirchner 1y 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 1y 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.
dang 1y ago
Recent and related: Twitter's new encrypted DMs aren't better than the old ones - https://news.ycombinator.com/item?id=44191591 https://news.ycombinator.com/item?id=44191591 - June 2025 (204 comments)
UltraSane 1y ago
The one that Musk tweeted has "bitcoin style encryption" even though bitcoin doesn't use any encryption.
- blueflow 1y ago
  I guess that encrypting a hash with ECDSA (= to generate a signature) does not count as encryption?
  - UltraSane 1y ago
    No, that is called signing and is not encryption.
    - deleted 1y ago
      [deleted]
    - deleted 1y ago
      [deleted]
    - deleted 1y ago
      [deleted]
    - pixxel 1y ago
      [dead]
  - SAI_Peregrinus 1y 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.
  - Benanov 1y 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.
wdb 1y ago
Pretty sure this problem has been resolved many decades ago.
vvpan 1y ago
[flagged]
- unstablediffusi 1y ago
  perhaps that's a sign that >99% of the world's population does not share redditors' political views.
- deleted 1y ago
  [deleted]
michaelt 1y 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 1y 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.
  - deleted 1y ago
    [deleted]
- delusional 1y 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.
afarah1 1y ago
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 https://proton.me/support/how-is-the-private-key-stored [2] http://srp.stanford.edu/ndss.html http://srp.stanford.edu/ndss.html [3] https://hacks.mozilla.org/2018/11/firefox-sync-privacy/ https://hacks.mozilla.org/2018/11/firefox-sync-privacy/
- bink 1y 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.
- matthewdgreen 1y ago
  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.
afavour 1y ago
> 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.
- stanislavb 1y ago
  You can't, and you shouldn't. That snake will bite the moment it whims.
- Sunspark 1y 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 1y 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.
  - VectorLock 1y ago
    Yappy one?
    - s-lambert 1y ago
      Probably referring to https://x.com/yacineMTB https://x.com/yacineMTB
  - dontlikeyoueith 1y ago
    > in particular the yappy one who was publicly inflammatory on Christmas Day. Well that's not a short list at X.
lxgr 1y 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.
- lxgr 1y ago
  Oh, just tried it myself: "Create a 4-digit passcode". Nope. To not even let users choose their own security tradeoffs with an optional longer passphrase seems very bad.
IshKebab 1y 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 1y 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.
  - IshKebab 1y ago
    You're not thinking sneakily enough. Obviously you wouldn't push a visibly malicious app update to everyone. Instead you make it so that you can push malicious code to specific users. Then all researchers can say is "it's a bit suspicious that this webview has access to Java APIs" and you just need to say "it's needed so we can get your app version" or whatever. They'll never be able to actually see you reading the messages, unless you happen to be very stupid and target a security researcher. I agree it's definitely better to do proper e2e encryption like WhatsApp / Signal do, but I don't think we should pretend they are magically fully secure against this attack.
    - danielscrubs 1y ago
      Apple doesn’t allow it?
      - IshKebab 1y ago
        As far as I know they do. You aren't allowed to dynamically load binary code but there's nothing against scripting or using JS in webviews.
nine_k 1y 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.
- deleted 1y ago
  [deleted]
BHSPitMonkey 1y ago
As a former user of XChat the IRC client (http://xchat.org/ http://xchat.org/), this rebrand makes me sad.
Leo-thorne 1y ago
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.
- extraduder_ire 1y ago
  Is it actually deployed already? I've noticed no change to the website to indicate it, and the "messages" section looks exactly the same.
  - Leo-thorne 1y ago
    Yeah, it’s live on the mobile app. You have to be verified and both users need to follow each other. Once I enabled it, there was a little lock icon on the chat, but the UI didn’t really change much beyond that.

129 points by vishnuharidas 1y ago

lenerdenator 1y ago

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

deleted 1y ago
[deleted]
barbazoo 1y 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.
- SV_BubbleTime 1y ago
  I gave a charitable reading to that comment as “in terms of trust”.
- robmccoll 1y 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 1y 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.
  - deleted 1y ago
    [deleted]
  - csallen 1y ago
    I think they meant client
- lenerdenator 1y ago
  Of course it's a requirement to be considered encryption. Let's take this "encrypted" copy of the text in your reply: " 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.
lxgr 1y 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 1y ago
  How do you know that the server is being handed encrypted content?
  - lxgr 1y 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.
    - lenerdenator 1y ago
      Does Xitter let you do that with the new feature?

nimbius 1y 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 1y ago
"Not your keys, not your crypto" - Not just for cryptocurrencies anymore.
- tialaramex 1y 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.

Kapura 1y ago

[flagged]

hbn 1y 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.

stefan_ 1y ago
Is anyone still clicking on that? It's just a billion group chat spam messages and grifter message requests.
deleted 1y ago
[deleted]
CobrastanJorji 1y 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.
- Sunspark 1y 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.
  - CobrastanJorji 1y ago
    And also SpaceX, of course. And the Tesla model X (as part of a series so he could have the models S, E, and X). And his son X. Well, X Æ A-12, but X for short. I hope that if I ever go crazy, there's someone who loves me that I trust that's around me to tell me when something I thing is cool is actually incredibly stupid.

tdeck 1y ago

Who is this for in the first place?

qualeed 1y ago
For Twitter/X users that want to communicate with each other using end-to-end encryption.
- dpkirchner 1y 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 1y 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.

dang 1y ago

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

UltraSane 1y ago

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

blueflow 1y ago
I guess that encrypting a hash with ECDSA (= to generate a signature) does not count as encryption?
- UltraSane 1y ago
  No, that is called signing and is not encryption.
  - deleted 1y ago
    [deleted]
  - deleted 1y ago
    [deleted]
  - deleted 1y ago
    [deleted]
  - pixxel 1y ago
    [dead]
- SAI_Peregrinus 1y 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.
- Benanov 1y 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.

wdb 1y ago

Pretty sure this problem has been resolved many decades ago.

vvpan 1y ago

[flagged]

unstablediffusi 1y ago
perhaps that's a sign that >99% of the world's population does not share redditors' political views.
deleted 1y ago
[deleted]

michaelt 1y 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 1y 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.
- deleted 1y ago
  [deleted]
delusional 1y 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.

afarah1 1y ago

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

bink 1y 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.
matthewdgreen 1y ago
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.

afavour 1y ago

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

stanislavb 1y ago
You can't, and you shouldn't. That snake will bite the moment it whims.
Sunspark 1y 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 1y 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.
- VectorLock 1y ago
  Yappy one?
  - s-lambert 1y ago
    Probably referring to https://x.com/yacineMTB https://x.com/yacineMTB
- dontlikeyoueith 1y ago
  > in particular the yappy one who was publicly inflammatory on Christmas Day. Well that's not a short list at X.

lxgr 1y 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.

lxgr 1y ago
Oh, just tried it myself: "Create a 4-digit passcode". Nope. To not even let users choose their own security tradeoffs with an optional longer passphrase seems very bad.

IshKebab 1y 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 1y 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.
- IshKebab 1y ago
  You're not thinking sneakily enough. Obviously you wouldn't push a visibly malicious app update to everyone. Instead you make it so that you can push malicious code to specific users. Then all researchers can say is "it's a bit suspicious that this webview has access to Java APIs" and you just need to say "it's needed so we can get your app version" or whatever. They'll never be able to actually see you reading the messages, unless you happen to be very stupid and target a security researcher. I agree it's definitely better to do proper e2e encryption like WhatsApp / Signal do, but I don't think we should pretend they are magically fully secure against this attack.
  - danielscrubs 1y ago
    Apple doesn’t allow it?
    - IshKebab 1y ago
      As far as I know they do. You aren't allowed to dynamically load binary code but there's nothing against scripting or using JS in webviews.

nine_k 1y 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.

deleted 1y ago
[deleted]

BHSPitMonkey 1y ago

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

Leo-thorne 1y ago

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.

extraduder_ire 1y ago
Is it actually deployed already? I've noticed no change to the website to indicate it, and the "messages" section looks exactly the same.
- Leo-thorne 1y ago
  Yeah, it’s live on the mobile app. You have to be verified and both users need to follow each other. Once I enabled it, there was a little lock icon on the chat, but the UI didn’t really change much beyond that.