{GIF of chat system running coming soon.}
This is a chat service for the SST CTF server. When complete, it will use RSA keypairs
for data encryption and SCP/SFTP for file transfer, making it quite secure. Users will
log in using their server logon name and the server will verify their identity through
~/.ssh/authorized_keys. If they are authorized, the server will allow them to
connect. The client will transmit his/her public key on login to enable secure
communications. This server will respond with its public key to facilitate this secure
communication. This key will be encrypted with the client's public key to help foil
man-in-the-middle attacks.
Coming soon.
How to install and run the service, coming soon.
The SST CTF chatd service is designed to be extensible and can work with many different client implementations. However, there are some requirements to effectively communicate with the server.
The handshake with the server (initial connection) begins with the client sending a username, immediately followed by a public key. The server will then respond with its own public key. Currently no encryption is available, and this spec will change when the beta is released to include encryption.
The format for message transmission is JSON-encoded strings, specifically JSON objects (more commonly known as maps or dictionaries). The server requires a message field, which contains the user's messsage. The specifications for standard communications also require the following:
| Key | Data Type | Use |
|---|---|---|
user |
string |
Name of sender |
message |
string |
Message to display |
color |
int |
The user's preferred color. This should be a curses color code (0-7). |
channel |
string |
The channel the message is sent on. Clients should have a channel subscribe function* |
Anything specified here must be sent by your client and can be expected to exist. You need not concern yourself with checking for the existence of these fields because they are required for the proper function of the client.
You may declare further data fields in your implementation, however you must check that they exist because other clients likely will not implement them. These can be used to add useful functionality such as nicknames, message formatting, and other message-specific signals.
* Channels are not server constructs. They are managed by the client. A user is always susbcribed to their PM channel, which is simply their username. These messages should be differentiated from standard messages (such as a dim 'from:' channel tag rather than the name of the channel). You may choose to implement a single-channel-only system or a multi-channel subscribe system, either is acceptable. However, note that the server does not log messages. If you wish to view all messages from a given channel, you should implement logging yourself.
Link to our CTF (Programming) team / club.
If you have any questions, feel free contact us: [email protected]. You can also contact the main author: [email protected].
Stephen Brimhall