server/keyexch: Store check-value key hash in the right place.

Another botch from de7bd20be1c41f8f70e98ab498ffb4a82800a9d8.  The
respond function stashes a hash of the peer's check value so we can
recognize it again without having to verify it fully.  Unfortunately, it
stashes it in the wrong slot, so (a) it gets overwritten immediately
afterwards, and (b) the code which actually tries to do the checking
finds some rubbish instead.

The most prominent symptom of this bug under normal circumstances is a
large number of bad-expected-reply-log warnings in the log file.  What
happens is that, after a successful key exchange, the two peers end up
quite precisely synchronized -- so much so, indeed, that they're very
likely to run the entire key exchange protocol truly simultaneously.  As
a result, we have to process both a full challenge and a reply, both of
which contain a check field.  The second time, this fails because of the
bug.  This continues until the two fall out of lock-step with each
other.

diff --git a/server/keyexch.c b/server/keyexch.c
index 76aeee00ff16880b8a2272edc577e9a0cc21c726..c2f035d47e082b3c2a77b93e62347a2df2cca43b 100644 (file)
--- a/server/keyexch.c
+++ b/server/keyexch.c
@@ -603,7 +603,7 @@ static kxchal *respond(keyexch *kx, unsigned msg, buf *b)
     h = GH_INIT(algs.h);
     HASH_STRING(h, "tripe-check-hash");
     GH_HASH(h, ck, indexsz);
-    GH_DONE(h, kxc->hc);
+    GH_DONE(h, kxc->ck);
     GH_DESTROY(h);
 
     h = GH_INIT(algs.h);