Skip to content

Gateway sign on

rebaserHEAD edited this page Oct 18, 2026 · 1 revision

reference, committed verified 2026-10-18 bootstrap c3409ba run 2026-10-18

Sign-on: the text exchange on its own connection that proves the password and ends in a game token. What the client sends in it is on Client protocol, and how it fits the gateway on Gateway.

The states

Sign-on takes a request at a time, and each request is accepted only in its own state:

State Accepts Then
New Connect Connected
Connected Login start, answered with a salt and the server's public value Login started
Login started Key data, the client's proof Authenticated on a good proof; back to Connected on a wrong one, so the client may retry
Authenticated Login finish, the account list, a game token request, and the client's request for its account's verified addresses, answered with an empty list, which the client takes as ready Stays

A ping is accepted in any state. Anything else, or anything out of order, ends the connection without an answer.

The exchange

  • The proof is SRP6 over SHA-256, with the account name in lower case as its identity, and the client's proof compared in fixed time. After the proof, both directions turn to RC4 under the proof's key. The client's bytes are decrypted from the end of its key data request, including any already read behind it.
  • An unknown account gets a salt and verifier derived from UnknownAccountSecret, stable per name. Its exchange runs exactly like a real one and fails at the proof, so nothing tells an attacker which accounts exist. Looking an account up costs the same work either way.
  • Every refusal carries the one error the client is known to take for a failed login, and some end the connection after it: a database that's unreachable, too many attempts from one address, or key values out of range.
  • The game token comes from the account owner once the client asks for it, and the time limit for logging in lifts then.
  • The reader takes a request split across reads, or two in one read, with fixed caps on the header and body sizes, and a body's length counts its UTF-8 bytes.

Known edges

  • Sign-on answers every refusal with one error, until the client's other codes are verified.

Where the code lives

Piece Path
The exchange, its reader, writer and errors Source/NexusTomorrow.Gateway/Sts/
SRP6 and RC4 Source/NexusTomorrow.Cryptography/
Tests Tests/NexusTomorrow.Gateway.Tests/, Tests/NexusTomorrow.Cryptography.Tests/

Clone this wiki locally