I wonder if it’s possible to do in the same way WhatsApp does for media uploads.
When you send a video to a contact on WhatsApp, it takes some time to upload the video. When you then forward the video a few minutes later, it’s near instant. This set off red flags for me, as that can’t be E2EE if so.
Someone explained that the media is encrypted using one key, which is stored locally. The key is then encrypted and transmitted to the recipient using the clients public key. When you forward the media, you only need to send the second recipient the encrypted key using their pubkey (along with the identifier for the media that is still present in WhatsApp server side cache).
This in itself raises some more red flags relating to the encryption of the media being transmitted and cached in the first place, but if that’s all done sensibly, then this isn’t the worst solution to reduce bandwidth utilisation by end users.
A similar approach could be used for E2EE group calls. Encrypt the payload using one key, send the payload to all participants via a central server (which generally has to happen anyway due to NAT traversal issues, especially with mobile internet), and send each participant the keys individually. Voila, group call with 3 people or 30 people doesn’t result in having to retransmit the same audio payload multiple times.
Obviously this is a simplistic overview of how this could work. I am not a cryptographer, I have no expertise in this area, everything above could be total baloney. Anyone with expertise should absolutely correct me please and thank you.
All that said, hope this helps.
EDIT: changed the above to reflect that forwarding media is “near instant” rather than “instant”
Thanks, I’ve edited the comment to better reflect that it’s near instant rather than actually instant.
I’ve done a packet capture to verify that my phone is not uploading the entire payload a second time when forwarding media I’ve recently uploaded or received, which is what compounded my original concern.
When you send a video to a contact on WhatsApp, it takes some time to upload the video. When you then forward the video a few minutes later, it’s near instant. This set off red flags for me, as that can’t be E2EE if so.
Someone explained that the media is encrypted using one key, which is stored locally. The key is then encrypted and transmitted to the recipient using the clients public key. When you forward the media, you only need to send the second recipient the encrypted key using their pubkey (along with the identifier for the media that is still present in WhatsApp server side cache).
This in itself raises some more red flags relating to the encryption of the media being transmitted and cached in the first place, but if that’s all done sensibly, then this isn’t the worst solution to reduce bandwidth utilisation by end users.
A similar approach could be used for E2EE group calls. Encrypt the payload using one key, send the payload to all participants via a central server (which generally has to happen anyway due to NAT traversal issues, especially with mobile internet), and send each participant the keys individually. Voila, group call with 3 people or 30 people doesn’t result in having to retransmit the same audio payload multiple times.
Obviously this is a simplistic overview of how this could work. I am not a cryptographer, I have no expertise in this area, everything above could be total baloney. Anyone with expertise should absolutely correct me please and thank you.
All that said, hope this helps.
EDIT: changed the above to reflect that forwarding media is “near instant” rather than “instant”