[oscargrouch]

The middle-man in this case is a trusted one, the owner of the centralized infrastructure, not like in MITM.

Isnt possible that one peer encrypt, pass it to the central server who have the other key, the central server than encrypts again and share it with the real end making it believe the key he is using actually is the same one generated in the first part of the process?

Its like the OR from tor but with 3 parties instead.

How the receiving party can be sure the key was not switched by the all-mighty middle man who can control everything?

[Thorrez]

> How the receiving party can be sure the key was not switched by the all-mighty middle man who can control everything?

From the article:

> Participants will also see the meeting leader’s security code that they can use to verify the secure connection. The host can read this code out loud, and all participants can check that their clients display the same code.

Obviously the vast majority of people won't do this, so the vast majority of people won't be fully protected against active MITMs. But the potential of meeting participants doing this will discourage attackers in many cases.

[zertrin]

Yeah in E2EE key distribution is always the tricky part.

For "good" UX, usually it is based on trust that the peer keys are exchanged with help of the centralised service as middle man but that it does not alter the keys.

For good security, each party should ideally check public key fingerprints with each other party via another mean of communication to ensure that there was no man in the middle. But that's poor UX and might be unpractical for large meetings of participants that do not know each other.