10

Last week Whatsapp introduced the end to end encryption to prevent man in the middle intercept/attack. The company claims that the data such as text, call, video, images and documents are stored nowhere in their server, only the concerned devices will be able to store or decrypt the data. But still the "Quick Image/Video upload" is working fine. The basic idea behind "Quick Image/Video upload" is to cache a copy of the uploaded images/videos in the server and when another user tries to upload the same content then the hashes are compared. If the hash matches then the server copy is used to avoid data usage. If the claim made by Whatsapp Inc. (regarding the end to end encryption without any server cache) is true then how is the "Quick Image/Video upload" still working?

Update

Thank you @TreyBlalock for sharing whatsapp security whitepaper: https://www.whatsapp.com/security/WhatsApp-Security-Whitepaper.pdf

Transmitting Media and Other Attachments:

Large attachments of any type (video, audio, images, or files) are also end-to-end encrypted:

  1. The WhatsApp user sending a message (“sender”) generates an ephemeral 32 byte AES256 key, and an ephemeral 32 byte HMACSHA256 key.
  2. The sender encrypts the attachment with the AES256 key in CBC mode with a random IV, then appends a MAC of the ciphertext using HMAC-SHA256.
  3. The sender uploads the encrypted attachment to a blob store.
  4. The sender transmits a normal encrypted message to the recipient that contains the encryption key, the HMAC key, a SHA256 hash of the encrypted blob, and a pointer to the blob in the blob store.
  5. The recipient decrypts the message, retrieves the encrypted blob from the blob store, verifies the SHA256 hash of it, verifies the MAC, and decrypts the plaintext.

Pointer number 3 is interesting here. So basically they are caching the attachments in their blob, that means they are of course storing the encrypted data in a device which isn't a communicating device.

Now the million dollar question: "Is your data safe? Is it out of reach from the authorities or the hackers?"

CodesInChaos
  • 11,854
  • 2
  • 40
  • 50
Ganesh Rathinavel
  • 201
  • 1
  • 6
  • 3
    It's possible they enabled end to end encryption simply for PR. The statement about end to end encryption (in transit) can be true and caching can still occur. Separately their claim about not storing certain types of data and yet being able to cache that data would be harder to believe unless they are implying that they don't store it but it is stored by a third party CDN (technically not them). Unfortunately it is common for companies to make statements that imply a feature exists, and are technically accurate, yet upon close inspection the details of their implementation seem appalling. – Trey Blalock Apr 09 '16 at 18:49
  • @TreyBlalock If both caching and end to end encryption are happening at the same time, then there is no integrity for the data we are sending, right? Even if the cache is happening in the server, when i upload a video it is encrypted using my enc key( & then cached) and when someone else is uploading the same video the enc key differs for him in which case there will be a mismatch in sha1, sha2 or md5 sums. If they are caching the videos without encryption then it isnt true end to end encryption! – Ganesh Rathinavel Apr 09 '16 at 18:52
  • 2
    https://www.whatsapp.com/security/WhatsApp-Security-Whitepaper.pdf https://github.com/whispersystems/libsignal-protocol-java/ It appears there are cases like group chat when the communications are not encrypted. Maybe the Quick Image/Video upload is also excluded from encryption. I don't have the answer but I do think you have found something interesting. It would be worth doing a WireShark capture of this traffic to look at it in more detail. – Trey Blalock Apr 09 '16 at 18:54
  • @TreyBlalock wow, that white paper was life saving. This paragraph explains it: 3. The sender uploads the encrypted attachment to a blob store. 4. The sender transmits a normal encrypted message to the recipient that contains the encryption key, the HMAC key, a SHA256 hash of the encrypted blob, and a pointer to the blob in the blob store. 5. The recipient decrypts the message, retrieves the encrypted blob from the blob store, verifies the SHA256 hash of it, verifies the MAC, and decrypts the plaintext. – Ganesh Rathinavel Apr 09 '16 at 19:02
  • 2
    @TreyBlalock Pointer number 4 and 5 to be noted. So basically they are storing the attachments in their blob! Huh interesting when you read `end to end encryption`, `no storage of data` and then this one. – Ganesh Rathinavel Apr 09 '16 at 19:02
  • Can't a MITM decrypt everything with the "encryption key, the HMAC key, a SHA256 hash of the encrypted blob, and a pointer to the blob in the blob store" from step 4? – miva2 Apr 14 '16 at 11:25

1 Answers1

1

All speculation wether what's app really uses e2e whenever possible (or if it's turned off with a kill switch whenever they like) aside:

If what the white paper describes is true, your data is fine in the blob, as it's encrypted reasonably well.

The only thing that would no longer work is data deduplication, e.g.

If a file with that hash is already present, do not upload it, signal the user success.

This creates a heavier load on the servers - and possibly phone data plans for people copying Videos instead of sending links.

Note that if you were to upload a file a second time, your device might cache the file and the corresponding keys and send a reference to the same blob-object, sharing the same keys as before, to multiple other users.

This would somehow at least lower the amount of data that has to go on the server for a single person sending the same file to multiple people.

Tobi Nary
  • 14,302
  • 8
  • 43
  • 58