Distributed IRC in TOR

Writing in regards to the design of an anonymous decentralized IRC server utilizing the TOR network.

The onion router has been in existence for quite a while, and the hidden services therein mainly remained in architecture the same. Likewise centralized IRC servers are found in TOR that does not solve the problem of a single point of failure. Therefore an alternative architecture is suggested and based on a decentralized principle. This implementation may result in one big anonymous, redundant, chatting onion.

Tor is a relay-network that uses layered encryption between nodes to enable secure anonymous transport of information. IRC is a centralized client server network, mainly used for chartrooms. Combining the two architectures with the gnutella node discovery methodology can result in a distributed, “peer-to-peer”, IRC enabled network, solving the dilemma of dependency on a centralized IRC server.

In order to implement such a system the following subsystems is required, as listed and elaborated upon below:

  • IRC client
    This is a normal third party IRC client that will connect locally to the TOR-IRC server.
  • TOR-IRC Server
    This is a custom IRC server that discovers other similar nodes and manages connections via the TOR network, also running locally, in essence basically a router.
  • TOR client proxy
    A locally run TOR client that manages the connection to the TOR network and serves as a SOCK proxy for the TOR-IRC Server to communicate through.
  • Gnutella web cache
    A modified gnutella web cache website, published within the TOR network to enable node discovery of TOR-IRC Servers. The only modification required is for the onion addresses instead of IP numbers.

Since the TOR client and the IRC client application is out of the box the remaining two subsystems is discussed.

TOR-IRC Server
This application consists of the following components:

  • An  IRC daemon ( or server) for local IRC client connections
    This daemon mimics the functionality of a centralized IRC server under normal usage scenarios.
  • SOCK protocol capability for connecting and  communicating with the TOR proxy
    The TOR proxy talks SOCK and not TCP, therefore this connection between the local IRC daemon and TOR is required.
  • TOR-IRC client instance manager.
    For each node discovered via a tor web cache a local management IRC client instance (router) is created, this instance then connects to the discovered node (since that node is a IRC server as well) and then to the local IRC daemon via a similar child instance. Server information is communicated through this node between the local IRC server and the remote IRC server.

After connection any users on the remote IRC server (this is usually one-to-one) when this subsystem recognizes it as such (eg. join), is created locally as a client instance, and connects in turn to the local IRC server.

The picture below depicts the interaction between the components

Conceptual Image

Certain countries may have legislation that prohibited users from using the TOR network, or legislation on free speech, or the publication of information may exist. Care should be taken with the information usually logged by normal third party IRC clients.

The ability of the TOR community to decentralize the IRC network therein would enable higher redundancy and decrease dependency on current centralized architectures.


TOR network
Gnutella webcache
The TOR-IRCd Concept Application
The TOR-IRCd Concept Application (Alternative Link)


Tags: , , , , , , , , , , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: