[OTR-dev] hash commitment in DH key exchange

[Ximin Luo]

On 27/05/14 20:39, Ian Goldberg wrote:
> 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

Thanks! I suppose this is the same reasoning as the DH-commit to protect the SAS in ZRTP[1]?

To clarify, does this mean the DH-commit is unnecessary if either:

a. the session key is longer, say 128 bits or 256 bits (but this would make it "less useable" for verification), or
b. we use a verification method that doesn't depend on the session id, such as direct fingerprint verification

Come to think of it, why does the SMP secret include the session id? Isn't the fingerprints enough? (I had thought perhaps this was to prevent replay attacks, but including the fingerprints should mean that no successful run of SMP is ever seen by a MitM, to be able to store and replay it later.)

X

[1] http://tools.ietf.org/html/rfc6189#section-7

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 880 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20140528/b0c2b58e/attachment.pgp>