|
|
|
|
|
|
by prmoustache
1622 days ago
|
|
|
I have always been a bit dubious about e2e encryption on whatsapp especially seeing how the forward message feature work. Example: upload a few minutes long video to a whatsapp contact, depending on your phone connection it can take up to a few minutes. Then forward it to other contacts or group and it is done instantaneously. For the videos and images to be sent and retrieved instantaneously by my contacts when forwarded while I am using a crappy connection it means they are retrieved from some whatsapp servers which means there is at least some kind of man in the middle proxy-cache stuff involved. I certainly cannot do the same on other apps I have used doing e2e encryption. On deltachat, atox, jami I have to send back again the data. While inconvenient when using a bad connection I am willing to get the tradeoff to have no mitm on any server. Anyone can share if there is a similar forwarding function on Signal? |
|
|
For example: Alice wants to send Bob and Claire a encrypted video. Alice encrypts it with a random key and uploads that video to FB's servers, at that moment (given the understanding that encryption is still uncrackable without throwing billions of cores at the problem) only Alice can decrypt that video hosted on those servers.
Alice then takes the link and the key and encrypts that message with Bob's public key and again with Claires public key, Alice then sends the messages to Bob and Claire (Ideally Alice and Bob / Alice and Claire would use a key exchange algorithm to create a ephemeral session key which would then be used to encrypt the key for the video). The message containing the key being sent to Bob and Claire is a lot smaller than the video itself, so it can be sent alot quicker/reliably over the crappy connection. It also removes the need to send the large file to each of the receptants (data transmitted = size of video * number of receptants) as you only need upload it once.
Bob and Claire can now each decrypt the message they got from Alice, get the link and the key, download the video, decrypt the video and play it. To whoever it was caching the video data, its just random data.
If throwing processing time at the problem is the attack vector then you can "just" listen in and record the wire as the data is being transmitted even if its a P2P conenction because its very likely that the data you are transmitting is going to get passed along some hops on its way to the receptant no matter which platform you use. If the attack vector is the messaging platform adding their own keys to the encrypted files, then they are in a position where everything is busted wide open anyways so it comes down to trust of that platform.
I'm not saying FB/WhatsApp are trustworty or not. I personally don't like using their services but people I know IRL do use their services which means if I want to take part in those converstations then I have to too.
EDIT: HOWEVER (this thought only popped in my head after hitting post) this does lead to some information leakage, Even though the message platform can not decode the video, they would be in a position to know if Bob or Claire accessed the video if they also control the caching platform used.