[OTR-dev] hash commitment in DH key exchange

[Ian Goldberg]

On Tue, May 27, 2014 at 05:43:32PM +0100, Ximin Luo wrote:
> Hi, I'm helping someone read over the OTR protocol spec atm.
> 
> I'm confused about the hash commitment in the DH key exchange. In the 2007 paper "Improved User Auth in OTR" it says:
> 
> "The channel itself uses a 64-bit secure session id based on the shared secret, which is short enough to be vulnerable to brute-force attacks. As a result, an initial commitment is used to ensure that neither party can base their choice of g^x on the other party’s value of g^y."
> 
> Why is the hash commitment necessary? The first sentence implies that Bob can set the session id to something they can predict, since (without the commitment) they receive g^x before they pick y. This is true, but it's not clear why this is a big deal.
> 
> I have never seen the session id in any UIs, but according to the protocol spec[1] it can be used for entity verification. I don't see how a session id controlled by Bob gives him any advantage. They are meant to be confidential - so it's not like you can try to collide to a session id with another conversation, because you don't know what it is.
> 
> I don't think the hash commitment hurts security, but it does add one extra round trip, so I'm curious what justifies this.
> 
> X

It's there to defend against a man-in-the-middle that can set both
halves' session IDs to the same value.  The MITM can let one side
complete, and then brute force a y such that g^{xy} has the right hash.
Even better, the MITM could cause both Alice and Bob to initiate with
him, and then he gets to choose y and y' to cause a collision, with the
commensurate birthday speedup.

(Very) older versions of pidgin-otr did in fact allow you to
authenticate the session by comparing (shortish) session ids, so this
defense was important.

   - Ian