0
$\begingroup$

Understanding end-to-end encryption, I ran into an issue which I wasn't able to find a solution for.

Given three parties: Alice, Bob, the chat endpoints, and the server party owned by Eve. The server party allows Alice and Bob to communicate.

Let's say Alice and Bob wanna start an encrypted chat session with each other. How do they prevent Eve from gaining and replacing the encryption keys (performing the MiTM attack) and compromising the whole session?

A meeting in person to share the secret is not an option.

I have read about OTR and Double Ratchet Algorithm. They claim to be secure and OTR claims to use the Socialist millionaire protocol, which, as I understand, should prevent the conversation to be compromised. But I don't quite understand how it works.

The main question is, is there a way for two parties establish a completely private conversation though a compromised server without using an outside channel?

Improve this question
$\endgroup$
6
  • $\begingroup$ For clarification: are you wanting to understand how Double Ratchet works, or in general how secure key exchange happens over an insecure channel? (Or both?) $\endgroup$
    – user47922
    Commented May 26, 2017 at 5:02
  • $\begingroup$ Well, mainly I want to know how the exchange happens and what are the techniques to prevent the server from replacing the keys. $\endgroup$
    – mrDoctorWho
    Commented May 26, 2017 at 5:13
  • $\begingroup$ Is a seperate Trusted Third Party an option for you? $\endgroup$
    – mat
    Commented May 26, 2017 at 7:42
  • 3
    $\begingroup$ Then, I am afraid, you are out of look. If you have not bootstrapped any trust between A and B and do not allow any communication apart from the KEX through a compromised channel, there is really no way to establish a trust relation between the two. $\endgroup$
    – mat
    Commented May 26, 2017 at 7:47
  • 1
    $\begingroup$ Note however that an after-the-fact verification of the long-term keys and thus the confidentiality of the previous messages is possible in most decent protocols. $\endgroup$
    – SEJPM
    Commented May 26, 2017 at 11:19

2 Answers 2

Reset to default
3
$\begingroup$

If Alice and Bob have no relevant secret knowledge not known to eve which controls the communication channel between them, it is impossible to create a seecure communication channel. Any protocol used, including diffie hellman, double ratchet socialist millioner or anything else can still be used with a MITM attack.

Eve takes the role of Bob when talking to Alice and the role of Bob when talking to Alice. Agreeing on two separate keys. The socialist millionaire will do no good because Bob shares a key with Eve.

To make this work we need either a pre shared public key for at least one party or a secondary communication channel to verify same key is used. We could use a public channel which everyone sees but Eve does not control. We could meet IRL and compare keys. We can use a voice channel assuming Eve won't be able to synethesize our voice in real time to recire a key commitment.(Deep learning is rapidly making the last assumption dubious).

Key exchange protocols work great with a passive eves dropper or when we have an authentication mechanism.

Improve this answer
$\endgroup$
1
$\begingroup$

The Socialist Millionaire method is described at that answer.

By using the Socialist Millionaire method Alice and Bob can prove to each other they possess the same preshared key, without revealing the secret to anyone.

If Eve interferes, the test fails and Alice and Bob will detect the interference. If the test passes, it has been proven that they arrived at the same session keys in the process (which involves 3 Diffie-Hellman exchanges), so they are safe to use for communication.

The preshared key doesn't need to be strong password, it just need to be something Eve doesn't know before the connection attempt is made. The eavesdropping is only possible if she knows the preshared key in advance and manages to authenticate with Alice and Bob separately.

Also the preshared key needs to be remain secret only during the time of the key exchange. It isn't a problem if it gets leaked afterwards (but then they will need another PSK for the next connection).

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.