ClientChallengeInitRequest

Answers ServerSessionReadyEvent. It carries your PUBLIC KEY - the value the server will check your proof against.

WHEN TO SEND IT

IMMEDIATELY ON ServerSessionReadyEvent, once, unconditionally. One construction site, no timer, no other path. That event closes the burst that follows a successful IdentificationRequest, so in practice this is the first thing you send once the session exists.

WHAT TO PUT IN IT

x             = your private exponent, drawn ONCE at start-up
challenge_key = decimal string of  G^x mod P

P and G are not secret, not negotiated and not per-session: the client hard-codes the RFC 2409 768-bit MODP group - "Oakley group 1" - which is a published constant, with G = 2 and Q = (P - 1) / 2. The whole handshake lives in that one group.

x IS PER-PROCESS, NOT PER-CONNECTION. The real client draws it once, when its verification service starts, and keeps it for the life of the process: 1024 random bytes read as a LITTLE-endian unsigned integer, then reduced modulo P. Every connection that process makes publishes the SAME challenge_key. Redrawing it per connection is not what the client does, and it is a difference a server can see across reconnects.

x IS THE SECRET THE WHOLE EXCHANGE PROTECTS. It never travels. Anyone who learns it can answer any challenge in your name, so treat it like a password rather than like a session value.

DO NOT CONFUSE IT WITH THE OTHER EXPONENT. ClientIdRequest publishes G^k for a throwaway k that changes on every poll; this one publishes G^x for the long-lived x. Both are decimal strings in the same group and they look identical on the wire. Sending the wrong one makes the proof fail with no useful error.

IT IS A CORRELATED REQUEST: the client allocates an envelope uid for it. Do not read too much into that - when ServerChallengeEvent comes back the client matches it by message type and never looks at the uid.

The server answers with ServerChallengeEvent, which you close with ClientChallengeProofRequest.

IT STAYS ON THE MAIN CONNECTION. While a fight-server transfer has a second socket open (see IdentificationRequest) the client routes outbound traffic by message type, and all three verification requests are pinned to the FIRST connection. Gameplay traffic is what moves to the fight server, not this.

THE COMPLETE ALGORITHM IS ON ONE PAGE. Constants, both exponents, both branches, what the server checks and the ways an implementation goes wrong are written out in full under ClientChallengeProofRequest. Read that before implementing any part of this exchange.