Quote from: ShadowOfHarbringer on October 22, 2013, 10:25:11 AM

But there were several mentions of alternative ways to mitigate MITM problem in this very thread. Is none of them valid ? (I will cite the previous mentions from this thread):

- "Rivest's Interlock Protocol can prevent a man in the middle from altering your communications while allowing you to communicate at all. At most, he is then reduced to an eavesdropper or able to engage a denial-of-service attack".
- "Bitcoin already has a solid public key infrastructure in that each and every coin is controlled by a public/private key pair. If you know who owns a coin, you can compose a message to them and encrypt it using that coin's public key".
- "ZRTP: For people seeking trustless key exchange algorithm: it has been already invented (i.e. you can avoid MITM attack without relying on PKI) - ZRTP could be easily adapted to bitcoin payments, changing SAS authentication string to PIN , for example, as it can be only 16 bit number. However, you would have to trust the merchant not to scam you".

Correct. None of them are valid. The interlock protocol does not do what the proposer thinks it does. Read the wikipedia page on it. It's a neat idea but it does not provide authentication. If there's a MITM sitting between you and the merchant, that MITM can rewrite traffic at will.

Bitcoin does not have a public key infrastructure. Using public keys does not mean the same thing as being a PKI. The "infrastructure" part means, how do you know the public key you have corresponds to the entity you think you're communicating with? The last part is tricky because "who you think you're communicating with" is a human, language-based concept, but cryptography works in terms of long random numbers. That's why we need certificates, to join those two worlds.

ZRTP is a method of triggering a Diffie-Hellman key exchange over a VoIP connection. It also isn't any form of authentication mechanism. If you use RedPhone or similar then the assumption is you read out the words you see on your screen, and that the other side checks that the words are the same. It's a neat idea based on the assumption is that a man-in-the-middle like the NSA can't forge your voice. It obviously doesn't work if the two parties don't already know what the other persons voice sounds like, so it's useless for securing a call to (say) a merchant, where you never talked to the salesperson before.

Like Gregory says, authentication and identity are just really hard problems. If you think you found a neat way to avoid all that overhead and hassle by browsing around on Wikipedia, you're probably wrong. Otherwise browser makers would be all over it by now.