Support E2EE Messenger

[kevincox]

Facebook has recently announced that Messenger conversations will be end-to-end encrypted by default. This makes support is effectively required for this bridge to continue.

https://engineering.fb.com/2023/12/06/security/building-end-to-end-security-for-messenger/

Support for a third-party client supporting E2EE would provide great assurance a that Facebook can't access your messages as no Facebook code would need to touch the keys. This would make Mautrix by far the best way to access your Facebook messages.

I don't know if it is possible to be full E2E, but encryption to the bridge would already be very powerful.

[immanuelfodor]

Just saw this article pop up and became worried instantly if we're going to loose the bridge by this change

[kevincox]

Please avoid saying "me too". It is clear that this will be important to all or most users. If you wish to explicitly share your support a 👍 is sufficient and doesn't notify all subscribers.

---

Looking more into the detail there are two whitepapers released:

• Messenger end-to-end encryption whitepaper discusses the P2P encryption scheme.
  • It appears that the crypto is based on the Signal protocol, so should be well understoon.
• Labyrinth encrypted storage protocol whitepaper explains the at-rest encryption for message archiving.

In both papers the crypto appears to be fairly specifically specified, but there is no API documentation. This largely makes sense for a protocol where they want to drive confidence in the security but have no interest in third-party implementations. While API documentation would be nice it seems that given the crypto it should be pretty easy to reverse-engineer the API, especially since they suggest that messenger.com will support the protocol as well.

Seeing that it is based on the signal protocol it seems that it may even be possible to do full E2E encryption. However this likely depends on the exact parameters used and I haven't do that comparison myself. I also don't know if that will continue to be true if Matrix moves to MLS. (But backwards compatibility may mean that it works for the forseeable future?) (This is not true due to metadata and message formatting, see the next message)

[tulir]

It will never be possible to do e2ee over bridges, except maybe when bridging the same protocol (and even then it usually has complications). The data format (the plaintext one inside encryption) is different, so even if clients could decrypt messages, they wouldn't understand them. Then there's things like user ids that are signed as a part of key exchanges that would be changed by bridges.

[immanuelfodor]

But the bridge could implement the e2ee device to keep the same functionality as now, right?
So it wouldn't be "truly" e2ee but still maintain the ability to use message bridging with FB-side e2ee chats:

Now: FB --unencrypted--> Bridge --optional encryption--> Client
With the current change: FB --e2ee--> Bridge --optional encryption--> Client

[BotBoiii]

tulir so do you plan on adding E2EE support (to the bridge) now or not? I don't think many people care whether the connection between the bridge and the user device is E2E.

I don't use the bridge, I'm coming from a different project but if we don't reverse engineer this I guess it will break altogether?

I've set up a discord server where we can meet to discuss reverse engineering of the new protocol https://discord.gg/8FWVYhQ7P5

[tulir]

The bridge will be updated at some point

[gabrc52]

It will never be possible to do e2ee over bridges

Well, of course the bridge would need to the decrypt the encrypted Facebook message in order to re-encrypt it for the Matrix user(s). But would it be possible for the bridge to encrypt it only for the recipient Matrix user and not to itself/its mxid, so that once the message is not in RAM, the bridge cannot see it anymore? That way, as long as users trust that the bridge is running the correct code, they will trust that the homeserver's admins cannot read their messages.

[tulir]

@gabrc52 https://docs.mau.fi/bridges/general/end-to-bridge-encryption.html

[1nikolas]

Just wanted to say some things I noticed:

1. E2EE is only enabled if both parties have enrolled E2EE
2. Messenger has 3 options for storing the chat history. The one that they try to push, which is what most people will use, is a 6 digit pin. To use other options you have to choose "Advanced options" (Other options are: store keys in Google Drive and only store messages locally, image^[1])
3. I can't seem to find a way to (temporary) turn this off so I can use the bridge
4. Their E2EE is made so Facebook Meta has access to all your chats. The e2e keys are managed on their servers and a new one is generated whenever you login on a new device without needing your phone to be on.

---

^[1] The options basically are: "store they keys on our servers", "store the keys on your Google Drive but give us access" or "store the keys on our servers but don't save history".

[BotBoiii]

4. Their E2EE is made so Facebook Meta has access to all your chats. The e2e keys are managed on their servers and a new one is generated whenever you login on a new device without needing your phone to be on.

I don't think you're right. I think if you log into a new device with all other devices offline you will not see the earlier chat history in the new device which means E2E would still be intact. But I don't have this enabled yet so feel free to check yourself.

[1nikolas]

4. Their E2EE is made so Facebook Meta has access to all your chats. The e2e keys are managed on their servers and a new one is generated whenever you login on a new device without needing your phone to be on.

I don't think you're right. I think if you log into a new device with all other devices offline you will not see the earlier chat history in the new device which means E2E would still be intact. But I don't have this enabled yet so feel free to check yourself.

Chat history is saved on their servers and you access it either using a pin or with your 2 factor authentication which means this gets saved on the server unencrypted.

But even if you were right about that, the new device would still get a key to receive/send new messages which makes it not entirely end to end (server can generate new keys, aka Facebook has a key for themselves to spy on messages for ads).

And even if it was proper end to end, I don't trust them. Their whole business is ads, it doesn't make sense for them to cut access to my messages, they'll loose money.

[olmari]

I'd say the ultimate "validity" of Facebook/Meta E2E implementation isn't the bridges concern, but as it exists and as being/becoming the default, now bridge users will need that to work and it is all we can hope for (I assume it'll happen with the newly announced Mautrix-Meta.

[BotBoiii]

Chat history is saved on their servers and you access it either using a pin or with your 2 factor authentication which means this gets saved on the server unencrypted.

I just checked, what you are saying ONLY applies if you use the secure storage feature which no one forces you to do.

Not trusting Meta is a completely different story but if you criticize them, criticize them based on facts and not based on lies which will destroys your credibility.

Generating new keys doesn't automatically make anyone able to read all your messages: The whole point of the Signal protocol is that precisely this is NOT possible.