From 5fb10b44d547dfcb3612b85e7115355301535ca0 Mon Sep 17 00:00:00 2001 Message-Id: <5fb10b44d547dfcb3612b85e7115355301535ca0.1715436356.git.mdw@distorted.org.uk> From: Mark Wooding Date: Sun, 14 Dec 2008 04:20:30 +0000 Subject: [PATCH] server/keyexch: Store check-value key hash in the right place. Organization: Straylight/Edgeware From: Mark Wooding 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. --- server/keyexch.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/server/keyexch.c b/server/keyexch.c index 76aeee00..c2f035d4 100644 --- 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); -- [mdw]