gpg authentication patch for tremulous;
Tremulous client and server run as a single thread, 20 'frames' per
second. Because of this time limit, the current system for identifying
admins on a server consists of a 32byte cookie named 'cl_guid' which is
stored (if the user has any admin priviledges) on the server in
admin.dat and sent by the client in plaintext at connect time. This is
less-than-ideal.
I don't think it would be too difficult to fork off an authentication
thread which uses pgp to do a proper signed-challenge authentication.
This would be a completely different thread and not constrained by the
50ms frame timelimit.
My suggestion, connecting clients optionally send a cl_gpgauth flag
which indicates if they're willing to gpg-authenticate. If the server
doesn't care then we don't ignore it (as an unpatched server will do)
and their guid is accepted as-is.
If we want to give them ops, the server requests they sent their public
key which is stored in the admin.dat in some appropriate manner.
If at the time they connect the guid they've sent is in the admin.dat
and has a public key, the server immediately sets their GUID to “”,
sends them a 'challenge' of 256 bytes (2048 bits) which is also stored
locally, and carries on. If they're in admin dat and don't have a public
key, no problem.. existing behaviour.
(There might need to be some kind of connection-rate-limit and
challenge-drop-time to prevent denial of service attacks on the server
at this point.)
Until they answer the challenge, or if they ignore the challenge
completely, they end up with an effective GUID of “”
Client binary, on receiving the challenge, forks off a gpg process to
sign the challenge block with their Tremulous private key. When the fork
ends (perhaps dozens of frames later) the next reply to the server will
include a detatched signature of the challenge data.
The server then forks off a GPG process and checks that they've
correctly signed the challenge block, and (again perhaps dozend of
frames later) if the gpg result is correct, their ingame guid is set
back to the one listed in the admin.dat, and existing server code
handles whatever privileges are implied by this. Result, connecting ops
have their guid set to "" immediately when they first connect, it should
only take a few seconds to do the authentication, and they'll have their
regular ID back faster than it takes to unpack all the models and
textures.
Note; cl_guid is not their gpg-key signature or anything like that, it's
still just a big random number, and the server keeps a record of both
only if there's any reason for them to be authenticated.
