On Wed, Mar 16, 2011 at 04:37:37PM +0100, Stefan Schönleitner wrote: > 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 ?
You've got it exactly right. Indeed, at one point in the history of OTR, checking the "secure session id" (which was exactly a truncated hash of a few things including the session key) out of band was something users could explicitly do. But in general, it's good crypto hygiene to prevent one party in a key exchange from being able to control the particular value of the key that comes out. - Ian _______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
