A deeper question is why we reached a point where people can't reasonably expect their communication to not be spied on.
The people have spoken, caring about your communications not being spied on puts you in the minority. I mean like, just look at social media. You have tons of people who not only don't care about being spied on, they actively document everything for more views.
Both parties exchange public keys through the central service. Only the possessor of the respective (on device, Secure Enclave ideally) private keys can decrypt the messages encrypted to the public key. The process can also work in reverse, encrypting with the private key so only holders of the public key can decrypt: this is called “signing”.
If the answer is blind trust in a third party that runs the messaging service then I suspect that you can guess what the people asking those questions are really asking.
If Meta are turning it off then I guess it's reasonable to assume that there is something to turn off.
If a messaging app is showing you message history in a private browsing window then perhaps the encryption key for that history is derived from your password or something like that; that can be done locally so that all the server ever sees is encrypted data.
edit: misread your message; if you have two sessions active at the same time, then yes I would expect both sessions to receive the same messages.
E2EE is a fail-secure design. In case of any doubt it deletes your private messages. When applied to this case I don't think the downside of constantly losing all your messages outweighs the upside of Facebook pretending they don't have a copy of all of them.
As to whether or not Meta have been lying about it, then that would be on-brand for them, but then what are they turning off if so? Or maybe the whole thing is theatre, and I should better disconnect from the internet altogether? I don't see the value in speculating about that.
To fix this, you either need to authorize each device (and web browser) from another device that's logged in, or the central authority holds your keys.
Eave could just do key negotiation with Alice and separately do key negotiation with Bob. You have to use a slightly more complicated cryptographic protocol to avoid this issue.
Fingerprints. Again, this is like Crypto 101. Not saying that as a personal attack of any kind, I just remain incredulous that what used to be entry level knowledge in “our thing” has evidently become so obscure.
Bob and Alice are setting up their e2e channel, and because they have some extra level of concern about snooping, they telephone each other and read off some form of hash of the public key to each other.
A more complex variant would be something like PGP implemented, where Bob and Alice could both sign each others keys after this exchange, ensuring that someone who hadn’t met Bob but did trust Alice could inherit trust in Bob’s Alice-signed key.
You’ve stated unequivocally that I’m wrong, so now, please show your homework.
The way military radios handle this is hardware key loaders that have seeds pre-synced in factory, in person. Every day in the field, a unit comms person takes the key loader and loads new keys onto everyone's radios. The key loaders themselves are reseeded and resynced during maintenance periods between campaigns or exercises. They're physically accounted for on every movement and twice a day when not moving, and if they ever can't be found, all messages from any device they loaded keys onto is considered compromised.
Anyone trying to overthrow a government or run a criminal empire or whatever is going to have to take measures at least this drastic. Or quit LARPing and accept that nation state attackers can probably slide into your Instagram DMs, which are probably being sent to people you don't know, and if they're hot and actually answering you, 90% chance they're a honeypot anyway.
Compromise of the secret key is a whole other issue - revocation.
MITM of a key can be solved pretty well via web of trust techniques.
Apologies if the dialog is frustrating to read! As a “recovering cypherpunk”, I find these sorts of discussions animating, as long as they’re polite and technically focused! Much love!
The tricky part is keeping it from being "permitted" by a crappy contract of adhesion. Banning it entirely would make it very difficult to buy/sell backup services...
For example, suppose the government demands constant access to your core database. You don't need to invent any new algorithms for that, you might just make an SQL user and a firewall exception and call it a day.
Similarly, If you have a messaging client, you don't need complex R&D to steal the "end-to-end" keys.
I’ve always been enamored of the idea of DNS as a back end protocol to enable the former largely decentralized solution.
Bob looks up Alice and receives her key from Alice’s namespace within the DNS hierarchy, along with her trust claims. David then looks up Alice’s key within her namespace, sees a reference to endorsement by Bob, and can validate this by querying Bob’s namespace. David can also issue non-authoritative queries about Alice’s key to Bob’s DNS servers, ensuring that there is no mismatch between the query response received by Bob and the one received by David.
If Mallory manages to compromise Alice’s DNS, but not Bob’s, the result is a mismatch in query responses that both Bob and David can thus detect.
At scale, a MITM compromising a system like this would be difficult without compromise of a large number of independent namespaces, increasing the likelihood of detection via the non-authoritative queries.
The missing component in this arrangement is cryptographic security of DNS, which I cynically suspect is why the DNSsec working group was comprised of the usual suspects and eventually produced a protocol without query encryption. It could still be layered on by a protocol extension, however.
The harder part that Instagram is most likely concerned about is getting low-effort users to keep their private keys safe without losing them.