[thenewwazoo]

Neat concept! This protocol appears to be a response to weaknesses in DH key exchange, which I understand to already be thoroughly broken. Can someone with more expertise perhaps explain if my understanding is correct, and whether this interlock technique is applicable or has been adopted anywhere?

[Kenji]

Yes, you are correct, it addresses the well-known possibility for an active eavesdropper in the DH protocol.

The interlock technique is very clever, I have never seen anything quite like it. However, at first glance, I do not know where the data blocks MA and MB for the interlocking come from. If they are hard-coded, breaking the scheme is trivial for C. If they are dependent on A or B, then we presuppose knowledge about the other party, and in that case, why not just use public key infrastructure with public keys for A and B?

I think the most important stepping stone that makes it hard to apply this protocol in practice is that you somehow need these blocks MA and MB of information that C does not have. If we are talking about voice samples here, it is likely that you can recognize them, but not your computer. Therefore, you'd also need some complex UI interactions to make sure it really is the other person. I'm having a hard time thinking about a practical application and its security implications right now.

[AKrumbach]

As I understood the paper, blocks MA and MB can have arbitrary contents as long as possessing the following block (MA' or MB' respectively) is required for decoding.

An eavesdropper cannot then substitute the contents of either MA or MB without either breaking the decoding process or dropping portions of the conversation. Either way, the eavesdropper cannot fully conceal their presence.