[OTR-dev] purpose of hash commitment in OTR authenticated key exchange

[Stefan Schönleitner]

Hi,

I was wondering what the exact purpose of the Diffie-Hellman hash commitment
in the OTR authenticated key exchange is.
The paper "Improved User Authentication in Off-The-Record Messaging" says
that the "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".

If there would be no hash commitment, the DH key exchange responder could
specifically choose g^y based on the choice of g^x which would allow him to
influence the resulting shared secret key s.
What's so bad about this ?

The only problem that i see is if Alice and Bob would for example verify
that there was no man in the middle attacker by comparing only the first few
bytes of the key fingerprint over a secure out-of-band channel.
Assuming that Alice establishes a DH key exchange with Bob in the presence
of a MITM attacher Eve, Alice would send g^x1 to Eve in the believe that she
sends it to Bob.
Now Eve initiates a DH key exchange with Bob by sending her own g^x2 whereas
Bob responds with g^y1.
The result is that the attacker Eve and Bob have agreed on a shared secret
s2 = g^x2^y1 = g^y1^x2 that has a certain fingerprint (e.g. F2 = sha1(s2)).
As for the authentication only the first few bytes of the fingerprint are
actually compared, in the key exchange with Alice the attacker Eve can
compute a special value g^y2 so that the established shared secret key with
Alice is s1 = g^x1^y2 = g^y2^x1, but with the big difference that the first
bytes of the fingerprint (e.g. F1 = sha1(s1)) are equal to F2.
If Alice and Bob verify the first bytes of the fingerprint with each other
over a secure channel, these bytes will be the same although there way an
attacker Eve in the middle.

However, if they would have compared the whole fingerprint with each other,
then it would have been computationally infeasible for Eve to compute a
special value g^y2 that leads to the same fingerprint.

Is this scenario the reason why OTR uses a hash commitment, or is there
another reason ?

cheers,
stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20110316/b53850a7/attachment.html>