I'm not sure what Diffie-Hellman has to do with anything here, but yeah, there's no reason encryption would prevent interoperability as long as all clients are using the same protocol (which they would have to do anyway in order to be interoperable).
Encryption makes it practically impossible to transform messages between different protocols, since the cyphertext contains not only the text content of the message, but also formatting, some attributes (e.g. `reply_to`). Even if it were the same, E2EE algorithms also differ between protocols, and you can't reencrypt the message for other protocols server-side.
I thought the opposite, at least as a first thought: Roughly two or three years ago, facebook announced their intent to integrate their messengers - so that you could send a message from your fb inbox to whatsapp, from whatsapp to instagram. And since whatsapp has E2E as a major part of their marketing, I'd think adding it to FB and IG rather than removing it from WA would be the way to go.
(though of course it's not REALLY: it harasses you to backup your messages all the freaking time, and when I say "never", as I ALWAYS do, it asks again in 2 weeks. I assume once they're backed up on Meta's servers, there goes the encryption. But that's a parlor trick and they STILL have that data, as I assume at least 80% back up anyway and the rest is mostly worn down by the constant prompting.)
That's because a single org controls all three messengers and they can develop them to converge to the same message format and to the same encryption mechanism. At the same point Signal or XMPP will use a different format and a different mechanism, making them incompatible with messages from Meta, unless a client with a private key reencrypts them.
but then, why do they not take no for an answer and keep nagging about it, and interpret "never" as "not in the next two weeks, but ask again, please!" if they don't have an interest in having these messages there?
(and no, "it's to help YOU, the hapless user! is of course never the right answer. Corporations never do things for users without an interest of their own.)
"How can we be sure a 3rd party implements the encryption properly" is the counter-argument.
How would you refute that? Trust users to check that some code is the same on both devices? What would prevent a bad actor from MITMing the whole thing from the start?
It's not man-in-the-middle, it's man-on-the-end. If your chat app wants to spy on you, there is nothing you can do, but at least it becomes obvious and easy to analyze because it's client side code. It's not a counter argument to interoperability. You need to trust both sides, the same way web works.
Hmm, but it’s OK to trust that web browsers implement TLS properly? And your router isn’t MITMing you? Or your SSH app exfiltrating all your server information? Why is this different?
Can it do so if the encryption and key management is at the client?
> Or your SSH app exfiltrating all your server information
That's a small niche, and most service don't expose SSH to public.
> OK to trust that web browsers implement TLS properly
hmm, you may have a point, maybe they'll ensure that only whitelisted browsers can access it, like Chrome with DRM for HTML. Only purpose is public safety. /s
FWIU, this[1] was decrypting imessages successfully. But was also storing all your imessages in a serverside database accessible to the server (instead of being e2e encrypted like imessage is supposed to be) and leaking the authentication token to access the imessages over unencrypted HTTP.
