No, it's not at all this simple. This is why so many "e2ee" apps like Telegram are bogus, they ended up prioritizing UX over security because there are many places where you can't pick both.
Webs of trust based on OOB key verification and signing, or centralized trust authorities are the two primary models I’m aware of.
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.
In practice it's possible to make a system that's hard to mitm if users are diligent. WhatsApp publishes a public record of hashes of the keys. If both sides check that record against their local keys, it's hard for WhatsApp to present different versions to each. Though that's a more recent development.
The harder part that Instagram is most likely concerned about is getting low-effort users to keep their private keys safe without losing them.
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.