An analysis of X(Twitter)'s new XChat features shows that X can probably decrypt users' messages, as it holds users' private keys on its servers
Technology
43
Beiträge
32
Kommentatoren
1
Aufrufe
-
This post did not contain any content.
If a corporate entity made it and hosts it, and it isn't foss, don't chat on it.
There is another layer here. If you or the person you're talking to are using an entirely unmodified android or apple phone, you don't have any privacy even if you're on TOR connected to an encrypted xmpp chat. Your entire existence is backdoored. The entire OS speaks back to its maker, especially that keyboard.
-
It’s not that I disagree with you on principle, I think you’re just kinda mixing up scenarios here, and the purpose of E2EE. E2EE refers to in transit data specifically. #1 should never be where your mind goes because E2EE does not imply your data will be encrypted at rest at the destination, that’s not what it’s for. E2EE is a critical factor when the untrusted facilitator party is between you and your intended recipient, not the recipient themselves.
Like in your scenario of a “cloud drive”, E2EE would not be a selling point of that service. The term you’re looking for in that scenario is “zero access encryption”.
Like you’re correct that E2EE does not imply that data stored in the cloud is encrypted at rest, but that’s because it isn’t meant to. Like this isn’t a dirty marketing trick. E2EE just needs to do what it says on the tin, which this X chat does not because they in order for it to be E2EE, it needs to be the case that only the recipient can decrypt it.
The third paragraph contradicts your other point. You define E2EE in two wildly different ways.
The chat messages are most likely stored on an intermediary server, which would qualify for the same loophole you pointed out in the cloud storage example.
-
inb4 the logo looks like this:
Nostalgia intensifies
-
Xchat is an irc client though.
This is the first thing that came to mind. I used that for ao many years, then went on to Hexchat.
-
This post did not contain any content.
No way. Impossible. Of course convenience never has a price tag.
/s for typical users of today's Web
-
The third paragraph contradicts your other point. You define E2EE in two wildly different ways.
The chat messages are most likely stored on an intermediary server, which would qualify for the same loophole you pointed out in the cloud storage example.
No it doesn’t, and I defined E2EE exactly one way. E2EE stands for “End to end encryption”, which means it’s encrypted at one end, decrypted at the other end, and not in the middle.
It doesn’t matter if they store a copy of your message on an intermediary server, the keyword there is intermediary. They are not the recipient, so they should not have the ability to decrypt the content of the message, only the recipient should. If they are able to decrypt your message, despite not being the recipient, it’s not E2EE.
A cloud drive is an entirely different case because the cloud drive is not an intermediary. They literally are the second E in E2EE. A cloud drive can have the ability to decrypt your data and still be E2EE because they are the recipient. You both seem to be under the impression that a cloud drive is an “intermediary” between your devices but it’s not. It’s a destination.
To explain it a bit simpler, imagine we’re in elementary school sitting at our desks and you’re sitting two desks away from me with one person between us:
E2EE = I encrypt my note with a simple cipher that I shared with you and only you before class. I pass my note to the kid between us to pass to you. He can’t read the note, and if he writes down a copy of my note before passing it to you it doesn’t matter because he still won’t be able to read it because he’s doesn’t have the cipher because he’s not the recipient, you are. He passes you the note and you can do whatever you want with it, including decrypting it, because you know the cipher. All the E2EE has done is ensured the kid in the middle can’t read the note. It has nothing to do with whether or not you can read the note.
Zero Access Encryption = I encrypt my note with a cipher that only I know. The kid in the middle can’t read this note, and neither can you. Then I use E2EE to encrypt that with a different cipher, the one that you do know, and hand the note to the kid in the middle to hand to you. The kid in the middle can’t read the note, and neither can you.
-
To extend this, that includes YOU giving your key to another application to decrypt those messages.
For example if you use an app or browser extension, that app or browser extension has access to that key. Additionally the browser itself or operating system had access to the key.
Now they may be fully audited. They may have a great reputation. You may trust them. But they are part of the decryption (and if sending encryption) process.
It's a chain of trust, you have to trust the whole chain.
It's a chain of trust, you have to trust the whole chain.
Including the entire other side of the conversation. E2EE in a group chat still exposes the group chat if one participant shares their own key (or the chats themselves) with something insecure. Obviously any participant can copy and paste things, archive/log/screenshot things. It can all be automated, too.
Take, for example, iMessage. We have pretty good confidence that Apple can't read your chats when you have configured it correctly: E2EE, no iCloud archiving of the chats, no backups of the keys. But do you trust that the other side of the conversation has done the exact same thing correctly?
Or take for example the stupid case of senior American military officials accidentally adding a prominent journalist to their war plans signal chat. It's not a technical failure of signal's encryption, but a mistake by one of the participants inviting the wrong person, who then published the chat to the world.
-
It's a chain of trust, you have to trust the whole chain.
Including the entire other side of the conversation. E2EE in a group chat still exposes the group chat if one participant shares their own key (or the chats themselves) with something insecure. Obviously any participant can copy and paste things, archive/log/screenshot things. It can all be automated, too.
Take, for example, iMessage. We have pretty good confidence that Apple can't read your chats when you have configured it correctly: E2EE, no iCloud archiving of the chats, no backups of the keys. But do you trust that the other side of the conversation has done the exact same thing correctly?
Or take for example the stupid case of senior American military officials accidentally adding a prominent journalist to their war plans signal chat. It's not a technical failure of signal's encryption, but a mistake by one of the participants inviting the wrong person, who then published the chat to the world.
Are you so sure Apple doesn't have your keys? How are they migrating the keys to your new device? It's all closed source
-
This post did not contain any content.
I mean, no yes man would enforce the fascist technocrat' order of reading all those messages. You know, the same technocrat who bought Twitter with Saudi money to cripple resistance movements and steer the public toward the alt right. The one with a thing for eugenics.
-
This post did not contain any content.
That's not what "private" means. If they have both keys, the wording "might be able to" is at best extremely misleading.
-
No it doesn’t, and I defined E2EE exactly one way. E2EE stands for “End to end encryption”, which means it’s encrypted at one end, decrypted at the other end, and not in the middle.
It doesn’t matter if they store a copy of your message on an intermediary server, the keyword there is intermediary. They are not the recipient, so they should not have the ability to decrypt the content of the message, only the recipient should. If they are able to decrypt your message, despite not being the recipient, it’s not E2EE.
A cloud drive is an entirely different case because the cloud drive is not an intermediary. They literally are the second E in E2EE. A cloud drive can have the ability to decrypt your data and still be E2EE because they are the recipient. You both seem to be under the impression that a cloud drive is an “intermediary” between your devices but it’s not. It’s a destination.
To explain it a bit simpler, imagine we’re in elementary school sitting at our desks and you’re sitting two desks away from me with one person between us:
E2EE = I encrypt my note with a simple cipher that I shared with you and only you before class. I pass my note to the kid between us to pass to you. He can’t read the note, and if he writes down a copy of my note before passing it to you it doesn’t matter because he still won’t be able to read it because he’s doesn’t have the cipher because he’s not the recipient, you are. He passes you the note and you can do whatever you want with it, including decrypting it, because you know the cipher. All the E2EE has done is ensured the kid in the middle can’t read the note. It has nothing to do with whether or not you can read the note.
Zero Access Encryption = I encrypt my note with a cipher that only I know. The kid in the middle can’t read this note, and neither can you. Then I use E2EE to encrypt that with a different cipher, the one that you do know, and hand the note to the kid in the middle to hand to you. The kid in the middle can’t read the note, and neither can you.
You probably didn't understand me. I'm saying that a company can just arbitrarily decide (like you did) that the server is the "end" recipient (which I disagree with). That can be done for chat messages too.
You send the message "E2EE" to the server, to be stored there (like a file, unencrypted), so that the recipient(s) can - sometime in the future - fetch the message, which would be encrypted again, only during transport. This fully fits your definition for the cloud storage example.
By changing the recipient "end", we can arbitrarily decode the message then.
I would argue that the cloud provider is not the recipient of files uploaded there. In the same way a chat message meant for someone else is not meant for the server to read, even if it happens to be stored there.
-
You probably didn't understand me. I'm saying that a company can just arbitrarily decide (like you did) that the server is the "end" recipient (which I disagree with). That can be done for chat messages too.
You send the message "E2EE" to the server, to be stored there (like a file, unencrypted), so that the recipient(s) can - sometime in the future - fetch the message, which would be encrypted again, only during transport. This fully fits your definition for the cloud storage example.
By changing the recipient "end", we can arbitrarily decode the message then.
I would argue that the cloud provider is not the recipient of files uploaded there. In the same way a chat message meant for someone else is not meant for the server to read, even if it happens to be stored there.
Alternatively, we need to stop saying E2EE is safe at all, for any type of data, because or the arbitrary usage.
-
You probably didn't understand me. I'm saying that a company can just arbitrarily decide (like you did) that the server is the "end" recipient (which I disagree with). That can be done for chat messages too.
You send the message "E2EE" to the server, to be stored there (like a file, unencrypted), so that the recipient(s) can - sometime in the future - fetch the message, which would be encrypted again, only during transport. This fully fits your definition for the cloud storage example.
By changing the recipient "end", we can arbitrarily decode the message then.
I would argue that the cloud provider is not the recipient of files uploaded there. In the same way a chat message meant for someone else is not meant for the server to read, even if it happens to be stored there.
I'm saying that a company can just arbitrarily decide (like you did) that the server is the "end" recipient (which I disagree with).
They cannot. Thats not how E2EE works. If they can arbitrarily decide that, then it isn’t E2EE.
That can be done for chat messages too.
It cannot, if you’re using E2EE.
You send the message "E2EE" to the server, to be stored there (like a file, unencrypted), so that the recipient(s) can - sometime in the future - fetch the message, which would be encrypted again, only during transport.
That’s not how E2EE works. What you are describing is encryption that is not end-to-end. E2EE was designed the solve the issue you’re describing.
This fully fits your definition for the cloud storage example.
It does not. Cloud storage is a product you’d use to store your data for your own use at your own discretion.
I would argue that the cloud provider is not the recipient of files uploaded there
It is if you uploaded files to it, like on purpose.
You’re confusing E2EE and non E2EE encryption.
-
Alternatively, we need to stop saying E2EE is safe at all, for any type of data, because or the arbitrary usage.
We don’t need to stop saying E2EE is safe, because it is. There is no arbitrary usage. Either it’s E2EE. If a company lies to you and tells you it’s E2EE and it’s not E2EE that’s not arbitrary usage, it’s just a lie.
