A basic question: How do you prevent man in the middle?

[badihi]

Hello guys, and nice job with the messenger!
I reached your homepage this morning and I became so interested in your project. But there is something I cannot understand.
You claim that the protocol is completely peer to peer and end-to-end encrypted. The question is, how is it even possible? Due to my knowledge of cryptography, there is no (regular) way to prevent man in the middle in absence of a CA in peer to peer encrypted communications. So it would be appreciated if you could enlighten me about this matter.
Isn't it possible for an adversary (maybe an evil ISP, for example) to sit between users and play the role of man in the middle in this protocol?

[nurupo]

In Tox users are identified by their Tox Id, which contains the public key. It's assumed that two users wanting to communicate via Tox have already exchanged their Tox Ids via a secure channel. With both users knowing each other's Tox Id, they can verify each other's identity, making MitM not possible.

Also note:

Authentication: Tox aims to provide authenticated communication. This means that during a communication session, both parties can be sure of the other party’s identity. Users are identified by their public key. The initial key exchange is currently not in scope for the Tox protocol. In the future, Tox may provide a means for initial authentication using a challenge/response or shared secret based exchange.

If the secret key is compromised, the user’s identity is compromised, and an attacker can impersonate that user. When this happens, the user must create a new identity with a new public key.

https://toktok.ltd/spec.html

[badihi]

So you mean that the key exchange is not a part of the protocol? So how are you doing that in this software? In clear text?

[badihi]

If the secret key is compromised, the user’s identity is compromised, and an attacker can impersonate that user. When this happens, the user must create a new identity with a new public key.

The problem is that in MITM attack the user will never know he is being impersonated!

[Green-Sky]

So you mean that the key exchange is not a part of the protocol? So how are you doing that in this software? In clear text?

what @nurupo wrote:

In Tox users are identified by their Tox Id, which contains the public key. It's assumed that two users wanting to communicate via Tox have already exchanged their Tox Ids via a secure channel.

Public-key cryptography

[nurupo]

So you mean that the key exchange is not a part of the protocol?

It is a part of the protocol. See the handshake in https://toktok.ltd/spec.html#net-crypto

What I mean is that there is no need for a CA. Since Alice knows Bob's public key and Bob knows Alice's public key before the key exchange happens, they can use ECDH to generate a shared key that only Alice and Bob would know, preventing the MITM attack. For the MITM attack to be successful, the MITM attacker would need to know Alice's or Bob's secret key.

The question is, how is it even possible? Due to my knowledge of cryptography, there is no (regular) way to prevent man in the middle in absence of a CA in peer to peer encrypted communications.

https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman

Btw, if you are looking to learn about AKEs, I suggest to look into Noise protocol. Even Tox is planning on integrating a Noise-based key exchange, as it would provide some additional security properties, e.g. the aforementioned user impersonation due to the secret key compromise wouldn't be an issue.

[badihi]

I'm aware of diffie-helman and public key encryption; MITM attack happens when parties do not know each other's public keys. You say exchanging public keys is not a part of this protocol and it is assumed to be done somehow else, via a secure channel (that is probably a centralized CA).
Actually, what is really interesting is a completely distributed way for general messaging, that non of its components are centralized. I was trying to find such thing in this project and the question was all about that; But it seems that it is out of the scope of this project.
Anyway I got my answer, so thanks for your time.

[goldroom]

@badihi
Exchange of static long-term ECDH/X25519 public keys (i.e. their ToxIDs) between two peers is not in scope of the Tox protocol. There is no CA for trust delegation, therefore trust establishment needs to happen out-of-band. If these public keys are exchanged via an insecure channel, an adversary may be able to perform a MitM attack. Please note that this is also the case e.g. when using Signal (that's why you need to compare safety numbers in Signal).
Static long-term X25519 keys are then used in the Tox protocol to exchange per-session ephemeral X25519 public keys, which are subsequently used to generate a symmetric session secret to be used with XSalsa-Poly1305 for AEAD encryption.
The current authenticated key exchange (AKE) in the Tox protocol is vulnerable to so-called "Key Compromise Impersonation" (KCI) attacks. KCI could potentially be used to mount MitM attacks, after a static long-term private key of a peer gets compromised. If you are interested in details in regard to KCI, see #426 (comment)