5 ms·
You can arrange a chat protocol, I think, where MITM isn't possible without being easily detectable in a low latency environment. The idea would be that when y
by shasta 13y ago
You can arrange a chat protocol, I think, where MITM isn't possible without being easily detectable in a low latency environment. The idea would be that when you see the "..." of the other person typing, you're receiving an encrypted copy of the letters of their message. When the message comes through it contains information needed to decrypt the message that was received over many seconds. You could always be chatting with an imposter, but a middle man would have to wait for the decrypted message before sending out the re-encrypted keys, which would add a big awkward pause before every response even started being typed.
- StavrosK 13y agoHmm, interesting idea, thanks. EDIT: I found the flaw: You have to wait until you have a full block before you can encrypt. If you send that, it's immediately decryptable. You can't send half a block, because you don't know the rest. Besides, the MITM can just pretend you haven't been typing until they receive the full message, and then start sending it.
- mkup 13y agoAnother interesting idea against MitM attacks on key exchange is implemented in ZRTP: verbal cross-check of two code words displayed on both terminals (during the first call) and key continuity (during subsequent calls). http://en.wikipedia.org/wiki/ZRTP#Authentication http://en.wikipedia.org/wiki/ZRTP#Authentication Cross-check of code words is essentially a humanization of RSA keys fingerprint cross-check. Only true geeks will speak hex digits over the phone, but normal people won't hesitate to tell a few words or small quizes/stories/whatever (if they need added security for this call).
- StavrosK 13y agoThe brilliant part of ZRTP isn't the cross check, it's using hash commitment to shorten the SAS to only 16 bits, from 160+. By the way, if anyone knows how a birthday attack is possible on the verification without hash commitment? It seems to me that the attacker has to generate a key whose fingerprint matches the fingerprint of the key they agreed on with the second recipient. However, this means that they have to generate a key to match a specific one, rather than multiple keys, hence no birthday attack is possible. What am I missing?
- shasta 13y agoI don't understand the first flaw you found. You can encrypt single characters + salt. You are correct that the MITM could wait until it's seen the whole block and pretend your partner hasn't started typing, but that results in big pauses with no typing after every question, which is detectable.
- StavrosK 13y agoIf you encrypt a single character, you can also decrypt that single character. What would that gain you? Also, what does the salt have to do with the encryption?
- shasta 13y agoForget the salt. I thought you were possibly concerned with encrypting one character being a weakness. As a recipient of my message you receive my message encrypted one character at a time. When I press enter you receive the key to decrypt all of these individual characters and can string them together into my message. I pick a new key and start sending the next message one character at a time. I'm thinking that any MITM attack will introduce noticeable latency into this scheme.
- StavrosK 13y agoHow are you going to send the key over the wire without anyone intercepting it?
- shasta 13y agoYou have a session key that encrypts the entire channel. A MITM attack would require negotiating two session keys: one for you and one for your human chat parter. Next you have a message key for each message that is used to encrypt and send each character and is sent at the end of each message (encrypted with the session key). A key detail I forgot to mention is that message keys should be tied to session keys so that the MITM can't just forward on the characters encrypted as they arrive.