quorumchat-development — Creating Quorum secure chat

[Quorumchat-development] Protocol

[Jesse S. <jes...@ya...>]

I am making headway on the communication protocol, it's about a third
done. Here is what I have done thus far. Suggestions and questions are
welcome.


Communication protocol?

There are essentially three types of message groups, client-to-server,
server-to-client and client-to-client. There are some basic rules which
will apply across all three scenarios. The first is that all messages
will have the format <command> [parameter1] [parameter2] .... For
example, the client might send this message to the server:

Iam 764efa883dda1e11db47671c4a3bbd9e

In the above example the command is “Iam”, which is followed by a space
and then the first parameter. Commands are not case sensitive, which
means the command “Iam” can be sent as “IAM” or “iam” or “iAm”, it's all
the same as far as the receiver is concerned. Likewise the md5sums
should be considered case insensitive.

The second common factor in each communication scenario is that clients
(and the server) tend to be lazy, that is they rarely “speak” unless
spoken to. For example, when a client connects to a server it will
introduce itself and then wait for a response. If the server responds
immediately, then the client will send a new query or piece of
information. If the server does not reply, the client assumes the server
is busy and waits. After a set period of time (around 30-60 seconds) the
client will try talking again. The exception to this “speak when spoken
to” approach is when a user sends a chat message. The client will
immediately send such a message out. If the server is asked to forward a
message, it will do so as soon as possible. This keeps chat flowing
while the routine protocol and information gathering is pushed to the
background. Hopefully this will prevent nodes from becoming overloaded
and keep things moving.


A) Client-to-Server
The client will send the following messages to the server and expect the
following responses...

Command: Iam [my_md5sum]
Response: Welcome | Newname
The md5sum is a 16-character string of characters in the range of 0-9
a-f. The server sends back either “Welcome” if it accepts the name or
“Newname” if it wants us to pick a different identity. Newname may
either indicate the name is too short or too long or someone else has
the same ID.

Command: Status [friend_md5sum]
Response: Status [friend_md5sum] online | offline | busy
The Status command indicates we want to know the status of one of our
contacts. We send the server the md5sum of our friend. The server
replies back with Status, the friend's md5sum and then their status,
which may be “online”, “offline” or “busy”.

Command: MyStatus <status>
Response: YourStatus <status>
This command updates the server with our status. Possible options for
our status are “online”, “offline” or “busy”. Normally we would only
send “online” or “busy”. The server sends back YourStatus followed by
our new status to confirm it has been accepted.

Command: Request <friend_md5sum>
Response: Request <friend_md5sum> OK | offline
When we want to add a contact to our contact list we send a request to
the server.  Assuming the other person is on-line, the server forwards
the request to the other person. If they then accept, the server sends
us back “Request”, the contact's md5sum and “OK”. If the other person
does not accept the request we receive no notice. If the other person is
not on-line at this time the server sends back “Request” md5sum
“offline”. This lets us know we can try again later.

Command: Accept <friend_md5sum>
Response: none
When the server sends us a friend request we can deny it simply by
ignoring the request. (Easy, right?) If we accept the request to become
friends, then we send the server “Accept” with the other person's md5sum.

Command: Block <friend_md5sum>
Response: Blocked <friend_md5sum>
Sometimes people annoy us. Sending the server “Block” with the other
person's md5sum tells the server to no longer allow messages through.
The server acts as a sort of firewall.

Command: Unblock <friend_md5sum>
Response: Unblocked <friend_md5sum>
If we have blocked a person and want to re-open communication we can
send the server a “unblock” command with the person's md5sum. The server
basically echoes this back to us to confirm.

Command: SendText <friend_md5> text
Response: TextOk | TextOffline <friend_md5sum>
If we want to send a contact some text which is not encrypted (like our
public key) we send “SentText”, the person's md5sum and the body of the
text. The server will send us back either “TextOk” with the person's
md5sum or “Textoffline” with the person's md5sum, depending on whether
it was able to forward the message.

Command: SendCode <friend_md5> data
Response: CodeOK | CodeOffline <friendmd5>
When we want the server to forward a coded message for us we transmit
“SendCode”, followed by the receiver's md5sum, followed by the data. The
response the server sends back is either “CodeOK” indicating the message
was forwarded or “CodeOffline” to indicate the message could not be
forwarded.

[Quorumchat-development] Progress, after a fashion

[Jesse S. <jes...@ya...>]

After some late night coding sessions I have put together the foundation
for a client and a server for this project. Right now they don't do
much, but the pieces are falling into place.

At the moment the server will wait for clients to connect, accept
messages from them and print messages received to the screen to confirm
the message was received. The client will allow the user to create a new
account, connect to the server, send an encrypted message and disconnect.

The next step will be to get the client and server speaking the same
protocol so they actually DO something when they talk.

On a side note I've been developing the client with modularity in mind.
At the moment the client is a graphical (GUI) application. However, all
the working parts are separate from the front-end display. This should
make it easy to create future clients that are command-line based or web
based.

I hope to set up a place-holder website soon with snapshots to download
so people can test drive what I've got so far.

- Jesse

[Quorumchat-development] Code repository

[Jesse S. <jes...@ya...>]

For the developers out there I have created a Subversion code
repository. Right now the code in there is pretty raw, it's mostly
snippets and pieces that I'm testing. Hopefully in the next week or two
it will start to take shape. To checkout the latest code snapshot, run

svn checkout svn://svn.code.sf.net/p/quorumchat/code/trunk quorumchat-code


- Jesse

[Quorumchat-development] Rough design draft

[Jesse S. <jes...@ya...>]

This is my rough draft of the design of the chat/file application.
Please feel free to post suggestions, questions, etc....


Secure chat message and file sharing software outline. Working title
“Quorum”


What? – Big picture

Quorum is to be a secure chat and file sharing service with a focus on
peer-to-peer communication. This will allow users to exchange messages
and files privately.


Why?

The Arab protests and similar protests around the globe have shown there
are times when people may wish to communicate peacefully and discreetly.
Governments all around the world have established laws (or are in the
process of adopting laws) which would allow them to monitor, track and
use network communications as evidence. In order to assist law abiding
citizens to communicate privately we hope to create a secure method of
communication which will not require any foreknowledge of encryption,
security certificates or networking protocols. The application(s) should
“just work” for the end user.



How? -- Big picture

Quorum will be divided into two pieces, a server and a client. The
server will have the fairly simple jobs of:

1. Maintaining a list of connected clients.
2. Initiating the handshake between two clients.
3. Passing messages between clients when they are unable to communicate
directly due to firewalls or filtering software.

The clients will have the ability to send messages to other clients,
either directly or (if direct contact is not possible) they will talk
through a server. Clients should also be able to send/receive files with
other clients.



How? -- Slightly more detailed picture

As an overview let's look at a typical day in the life of a client. We
start out by connecting to a known server. We provide the server with
our ID. Let's say we want to form a connection with our friend, Susan.
We ask the server to pass a “friend” request to Susan. If Susan accepts
our request, then the server helps us exchange IP addresses and public
security keys. We attempt to connect to Susan, but something is in the
way. We pass a message to Susan (through the server) asking her to
connect to us. Susan connects to us directly and we can exchange
messages back and forth directly.





About the security?

At the moment my idea for dealing with security is to have two levels of
message encoding. Communication between the server and a client can be
encrypted using secure socket layer (SSL). Communication between one
client and another client I think should use a unique RSA key which is
A) only used for that session and B) exists only in memory. This should
prevent keys from being stolen or users being asked to hand over their
keys to someone else. In a third scenario, clients may be forced to
communicate through a server (Client->Server->Client), if this happens
then the connections between the server and clients should be sent over
SSL, and the messages embedded inside the SSL stream will be encoded
using RSA. This prevents the server from listening in on the
communication. ie The server knows who is communicating, but it does not
know what is being said.




Technology?

It is my thought to write the server and client software using the
cross-platform Qt C++ library. Qt provides secure socket code, threads
and graphical user interface classes which should make writing and (most
of all) porting the software fairly straight forward. Copies of Qt
(including the libraries, graphical development suite and documentation)
can be found in the Qt SDK bundle located here:
http://qt.nokia.com/downloads

On the hardware side of things any fairly modern computer with a
graphical interface should be able to run a Quorum client. For testing
and deployment we will eventually need a server. The hardware
requirements for the server will be low (at least at first), but it will
have to be available 24/7. Ideally I think the server should be running
stable version of Linux.




Communication protocol?

The specific protocol between clients and server and clients with
clients is still a work in progress...

[Quorumchat-development] Working to-do list

[Jesse S. <jes...@ya...>]

The following is a list of items I think will have to be done early on
to make sure the project gets up and running.... These are broken into
separate categories for coders, designers, artists/writers and hardware.

Please feel free to add items to the list.

- Jesse



Code:
        Automate certificate/key creation.
        Automate certificate/key deletion.
        Set up basic client/server communication.
        Make sure clients/servers disconnect cleanly.
        Create basic client/server authentication.
        Allow clients to connect to each other.


Design:
        Create protocol outline for client/server.
        Create protocol outline for client/client.
        Establish way for clients to uniquely identify themselves.


Art/Info:
        Create website.
        Create logo.
        Create user documentation.
        Create SVN code repository.


Other:
        Acquire access to Linux box to host server program.

[Quorumchat-development] Test e-mail

[Jesse S. <jes...@ya...>]

Test e-mail to make sure the list works.