Signal
Comment on Lawsuit Alleges That WhatsApp Has No End-to-End Encryption
RIotingPacifist@lemmy.world 9 hours agoWhat are the better alternatives, because it seems like the comment section is flooded with people (yourself includes) that don’t understand that most (probably all) e2e messaging apps are vulnerable to this attack as long as they trust a centralized server.
The issue isn’t an encryption one, it’s a trust one that requires you to trust the makers of the messaging app and the servers the apps connect to (and the method by which the app is distributed to you).
just_another_person@lemmy.world 9 hours ago
RIotingPacifist@lemmy.world 9 hours ago
You’re just replacing trust in Meta with trust in Signal without understanding why Meta is vulnerable to this.
Is Signal more trustworthy, probably, is Signal safe from the attack described, absolutely not.
axx@slrpnk.net 9 hours ago
Theoretically, you can check the code actually running on the Signal servers is the code they publish under a free and open source licence, using the hardware-based TEE attestations the servers will return
Someone more knowledgeable than me may have managed to do so, I haven’t.
felbane@lemmy.world 9 hours ago
Tell me you don’t understand how Signal’s E2E mechanism works without telling me you don’t understand how Signal’s E2E mechanism works.
RIotingPacifist@lemmy.world 8 hours ago
Tell me you don’t understand what E2E encryption is without telling me you don’t understand that the limits of E2E encryption.
just_another_person@lemmy.world 9 hours ago
See every other comment in this thread describing in great detail why you are wrong, but that you fundamentally DO NOT UNDERSTAND how any of this works whatsoever.
RIotingPacifist@lemmy.world 8 hours ago
You fundamentally DO NOT UNDERSTAND how security works, go play with your algorithms and stop spamming my replies.
anon_8675309@lemmy.world 8 hours ago
This is key and I don’t think Signal shies away from this. You MUST trust the code you’re running. We know there are unofficial Signal builds. You must trust them. Why? Because think of it this way. You’re running a build of Signal, you type a messages. In code that text you type then gets run through Signal’s encryption. If you’re running a non-trustworthy build, they have access to the clear text before encryption, obviously. They can encrypt it twice, once with their key and once with yours, send it to a server, decrypt theirs and send yours on to it’s destination. (for example, there’s more ways than this).
Pika@sh.itjust.works 8 hours ago
Just because it’s centralized doesn’t mean that it falls under this risk sector. Theoretically if the app was open sourced and was confirmed to not share your private key remotely on generation (or cross sign the key to allow a master key…), then the most the centralized server could know is your public key, the server wouldn’t have the ability to obtain the private key (which is what is needed to read the e2e encrypted messages)
This process would be repeated for the other party. The cool part of that system is you can still share your public keys via the centralized server, so you wouldn’t need to share the key externally. You just need to be able to confirm that the app itself doesn’t contain code to send your private key to the centralized server. Then checking integrity is as easy as messaging your friend to post what their public key is, and that public key would need to match the public key that the server is supplying as your contact.
The server can’t MiTM attack it because the server has no way of deciphering the message in the first place, so the most it could do is pass the message onto the proper party whom has the private key to be able to decrypt it.
RIotingPacifist@lemmy.world 8 hours ago
Just because it’s centralized doesn’t mean that it falls under this risk sector.
The attack as described almost certainly involves the server sending a message to your client and then having the messages replicated via a side channel to Whatsapp without breaking E2E encryption (it could be adding them as a desktop client or adding them as a hidden participant in all chats, that isn’t clear in the article)
If you could run Whatsapp without connecting to Meta, you would be safe from this attack, but as you’ve pointed out a secure client is a better solution.
Pika@sh.itjust.works 7 hours ago
Fully agree that in this case if the claim is true (they have had a few of these claims), it’s likely whatsapp either making itself a companion app that’s hidden, or has some form of escrow in place to allow deciphering the messages.
I was just mentioning that this isn’t a fault of it being centralized, this is a design choice by the company when implementing e2e encryption, and that a properly functioning system would never give the server the ability to decipher the messages in the first place.
Maestro@fedia.io 9 hours ago
With e2e you don't need to trust the servers. You only need to trust the client that does the encryption.
RIotingPacifist@lemmy.world 8 hours ago
The attack as described almost certainly involves the server sending a message to your client and then having the messages replicated via a side channel to Whatsapp without breaking E2E encryption.
But yes the point is you can’t trust the clients.
If you could run Whatsapp without connecting to Meta, you would be safe from this attack, but as you’ve pointed out a secure client is a better solution.
axx@slrpnk.net 9 hours ago
Element / matrix.
Zak@lemmy.world 8 hours ago
Signal uses reproducible builds for its Android client, and I think for desktop as well. That means it’s possible to verify that a particular Signal package is built from the open source Signal codebase. I don’t have to trust Signal because I can check.
If I don’t have extreme security needs, I don’t even have to check. Signal has a high enough profile that I can be confident other people have checked, likely many other people who are more skilled at auditing cryptographic code than I am.
Trusting the server isn’t necessary because the encryption is applied by the sender’s client and removed by the recipient’s client.