How it works

Architecture

Global architecture of pyChatter

The architecture of pyChatter is based on the SPADE MAS platform.

The SPADE platform

SPADE (Smart Python multi-Agent Development Environment) is a Multiagent and Organizations Platform based on the XMPP/Jabber technology and written in the Python programming language. This technology offers by itself many features and facilities that ease the construction of MAS, such as an existing communication channel, the concepts of users (agents) and servers (platforms) and an extensible communication protocol based on XML, just like FIPA-ACL. Many other agent platforms exist, but SPADE is the first to base its roots on the XMPP technology.

So, pyChatter relies on SPADE.

The Directory Facilitator

The Directory Facilitator (DF) is a yellow pages index where the services offered by the agents are published for others to find. The way of publishing services is by uploading to the DF agent a set of service descriptions that contain information about services and how to access them. Each agent can publish its own set of service descriptions.

Bob uses the DF to get the list of connected clients and in order to find Alice. But first Bob has to find the authentication agent in order to ask for the public RSA key of Alice and Alice's ontology.

Client agent

Source code of this agent.

A client agent is composed of 4 behaviors:

  • ReceiveMessageFromAuthenticator
  • SendMessageToAuthenticator
  • ReceiveMessage
  • SendMessage

Authentication agent

Source code of this agent.

An authentication agent is composed of 2 bahaviors:

  • ReceiveMessage
  • SendMessage

This agent is in charge of serving requests of clients.
Responsibilities:

  • manage the XML file of known client agents;
  • provides informations (ontology, public key) to a client about an other client.
<?xml version="1.0" ?>
<clients>
    <client>
        <name>bob</name>
        <password>SHA1-passwd1</password>
        <ontology>ontoBob</ontology>
        <pubkey>852108226377068099189013827967614161814751239069790865842003264836998788599-3327597226355360752240509143823667932398233888705850172102303059140566684181</pubkey>
    </client>
    <client>
        <name>alice</name>
        <password>SHA1-passwd2</password>
        <ontology>ontoAlice</ontology>
        <pubkey>11347006007938364972149874045838784213460379266675473661344727140523294462453-30558630840867788209589812942204548998310405321872688415855895716973064710441</pubkey>
    </client>
</clients>

This is the key file for the authentication system. Only readable by the authentication agent.
This file is created by the authentication agent with the informations provided by client agent at registering. So the client has to generate a public key and send the public part to the authentication agent. The private part is kept locally.

When for example Bob wants to chat with Alice, he just has to select Alice via the appropriate menu ('Management of interlocutors'). By doing this, Bob will automaticaaly retrieve needed informations about Alice. So, Bob will be able to encrypt messages with the public key of Alice. And Alice well decrypt the message with her private key.

Of course, Bob can send a message to Alice and Oscar at the same time (after having added Alice and Oscar to the conversation). The message will be encrypted with the public key of Alice and sent to Alice, then encrypted with the public key of Oscar and sent to Oscar. So all the recipients (Alice and Oscar) have to own the corresponding private RSA pair. Otherwise, they will not be able to decrypt the message.

Security

Communications

RSA

Communications between interlocutors are encrypted thanks RSA algorithm.
Implementation used for RSA.

Future encryptions algorithms:

  • ElGamal ;
  • Rabin..

Authentification

Challenge-Handshake Authentication Protocol

The clients authenticates themselves to the main server using the CHAP protocol.

Steps :

  1. the authenticator (main server) sends a "challenge" message to the peer (client) ;
  2. the peer responds with a value calculated using a one-way hash function, using SHA checksum hash ;
  3. the authenticator checks the response against its own calculation of the expected hash value. If the values match, the authenticator acknowledges the authentication; otherwise it should terminate the connection ;
  4. at random intervals the authenticator sends a new challenge to the peer and repeats steps 1 through 3.

The challenge is the hashed value of the client password concatenated to a random number. The whole is hashed and represents the challenge.
The main server sends the random number to the client which in the same way calculates the challenge and sends it to the main server for comparaison.

Graphical user interface

The interface has been developed with Tkinter. The goal was to to have a really simple interface. I'm not really keen about interface development.
The text zones supports UTF-8 encoding (useful for example for French users).
I could have develop an instant messaging software in text mode, but it's not really fun to use ;-)

Logo of pyChatter

pychatter-logo-128x128.png

The logo of pyChatter comes from the Oxygen Project and is under GNU Lesser General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-NonCommercial-ShareAlike 3.0 License