Hacker News Reader

Comment by pgalvin | Hacker News Reader

Helpfully given in the introduction, here is some useful context for this change in case some people miss this part:

> Since 2016, all personal messages, calls, video chats and media sent on WhatsApp have been end-to-end encrypted. […]

> WhatsApp’s backup management relies on mobile device cloud partners, such as Apple and Google, to store backups of the WhatsApp data (chat messages, photos, etc ) in Apple iCloud or Google Drive. Prior to the introduction of end-to-end encrypted backups, backups stored on Apple iCloud and Google Drive were not protected by WhatsApp’s end-to-end encryption. Now we are offering the ability to secure your backups with end-to-end encryption before they are uploaded to these cloud services.

View on HN

I'm pretty sure both Apple and Google are very happy with the current state of affairs, this system works great to keep people locked into IOS or Android, as exporting your data is super hard (there were a number of expensive sketchy-looking apps that claimed to be able to do this)

https://wabetainfo.com/how-to-migrate-your-chat-history-from...

This is possible now (in one direction, so far).

Slight Nitpick: This is only available for Apple to Samsung devices.

However,

> Unfortunately, it’s still not possible to migrate your chat history [from iOS] to a different Android phone, but WhatsApp is planning this in the future. It’s also not possible to migrate your chat history from Android to iOS right now.

It used to be encrypted before upload to google, and then … one day it just wasn’t (but came with the “candy” that it no longer counts against your account quota). I could never found any explanation for this, best hypothesis I found is that it’s a backdoor for law enforcement without admitting it.

I would be surprised, given everything happening in the world today, if the new system does not somehow allow law enforcement to get access (possibly indirectly, through the app giving the key in some weird back channel)

Fwiw, that “encryption” never used your own key or password. Facebook held the key, Google held the encrypted blob, and I doubt the extra warrant to get data from both companies was a huge hurdle.

Definitely was not E2EE before.

That's correct. And yet ... back then, Google couldn't read your messages; Facebook couldn't read your backup; And hackers or law enforcement would need to both get a copy of the blob from Google and the key from Facebook - not insurmountable, but requiring a lot more work and more likely to raise suspicion.

Whereas ... after that change, Google can read your messages, hackers/law-enforcement only need to talk to Google, and yet -- you yourself can't get that backup without impersonating the WhatsApp app to Google Drive; The local backup is still encrypted with a key that only Facebook knows (and would give you, but only if you impersonate the WhatsApp app when talking to Facebook).

I've looked for the logic and failed. Only reasons I can find is that FB wants to let Google index your messages behind your back (unlikely) or some plausibly deniable legal backdoor.

If you read Texas's antitrust lawsuit against Google, you will see that FB and Google signed an exclusive agreement, where Google gets access to WhatsApp messages stored on Drive in exchange for [redacted].

https://www.theverge.com/2020/12/17/22180258/google-whatsapp...

Ah so that's how it worked? I heard that concept once and thought it was a really interesting way to ensure a user wouldn't lose their backup while preventing the company from accessing it.

It's not solely law enforcement. It's a commercial deal.

https://www.theverge.com/2020/12/17/22180258/google-whatsapp...

Deduplication could be a thing

Incredibly unlikely. The backup is AFAIK an SQLite file that contains the text messages (and indexes, etc). The bigger files - images, videos and voice messages - are not included in that backup, and are backed up independently to Google Photos (and always have been).

And that's why I kept saying "no" to the backup requests in WhatsApp.

Doesn't matter; everyone else you talk to on WhatsApp is uploading those same conversations to Apple and Google effectively unencrypted.

I mean that's the problem of any protocol in general. Your opsec can be great, but if it relies on someone else's opsec...

What do you do instead? Replies like this I may mistakenly interpret as "doesn't matter, so I'll do nothing about it" which is just an excuse.

I deleted my Facebook, WhatsApp, and Instagram accounts, as well as iMessage/iCloud (same issue, unencrypted backups).

I am only reachable via email and Signal. I got my contacts to switch to Signal.

How does that solve the problem you mentioned? People on other side still may not be careful with mail/signal data privacy.

Mail is beyond redemption, but Signal for example only offers encrypted local backups and no cloud backups.

And that is why I dont use WhatsApp. Self hosted matrix is super awesome.

Why is this being called E2EE? If you're uploading them, shouldn't they be encrypted at rest? Why would we want it decrypted on the other end? I just want to upload an encrypted file that can only be decrypted by my app. No other end.

In this case both ends are you. You could back up on one phone and restore on another.

You're right that "E2E" is slightly ambiguous. But "encryption at rest" is even worse in my opinion, since it could just mean that Apple/Google's datacenters have disk encryption with a key they can access.

I am neither the authority to define "encryption at rest", nor am i saying "encryption at rest" is good wording in this case.

But from my understanding, "encryption at rest" is not disk encryption.

If you have a database with disk encryption, once the disk crypto key is entered an attacker could try to "do hacker stuff" and exfiltrate the WAL files.

If you have "encryption at rest", the WAL files are written encrypted and are decrypted on read. An attacker may get your WAL files, but they are still encrypted.

There are likely multiple definitions. This Azure definition disagrees with you:

>Encryption at rest is designed to prevent the attacker from accessing the unencrypted data by ensuring the data is encrypted when on disk. If an attacker obtains a hard drive with encrypted data but not the encryption keys, the attacker must defeat the encryption to read the data.

https://docs.microsoft.com/en-us/azure/security/fundamentals...

So with this definition encryption at rest has the threat model of an attacker who can physically steal a hard drive but not the hard drive's encryption key.

Well if Facebook is encrypting I'm hoping Apple/Google can't decrypt on their datacenters. That would be really weird. Just with the key that I hold (aka my app account). I've always understood E2EE as an in transit thing or public/private key where it is encrypted till the other end. I definitely want my backups sitting at rest on some server where I have no ends and it is just a loop.

>Well if Facebook is encrypting I'm hoping Apple/Google can't decrypt on their datacenters.

I was referring to the prior backup scheme where Facebook wasn't encrypting. It could accurately be described as encrypted at rest I think, but yet Google and Apple could read the contents I think.

>no ends and it is just a loop.

The terminology is getting pretty confusing at this point. I usually think of the ends as the intended parties to look at the data. If there are no ends, then no one will look at the data, meaning the data is useless. Actually if there's no beginning end, there's no one to create the data, so thus the data doesn't even exist.

Next step is who owns the key, if it is FB that kills E2E story. If it is user, they'll forget/lose it, so it doesn't scale to 2B users. Currently Apple/Google are set as the custodians of the key.

From the pdf, it sounds like the HSM owns the key, and will only give it up if the correct password is provided.

The data could probably be exfiltrated via WhatsApp web?

Still not total encrypted but getting there.

Reply on news.ycombinator.com