http://www.invisiblenet.net/iip
http://127.0.0.1:8888/SSK@Q7~eGjIY3rVWh4pcFv~zK2LZ4XQPAgM/iip//
[TOC to be done]
The Invisible IRC Project (IIP) was created for the obvious intent of bringing people interested in privacy and free speech together in a forum where development of these goals could be done in an equaly secure environment. The project's inspiration came mainly from the growing interest in the Freenet Project and Freenet's incapacity to carry real-time communication.
The software is provided AS IS without warranty, either expressed or implied. The IIP development team cannot be held responsible for the actions of the users of this software.
This software and document are released under the GPL license. See
gpl.txt included with the software.
This document should be able to provide you with the following understandings:
This document is maintained by cohesion. Any revision, comment, or question can be directed to the project leader, 0x90 (0x90@invisiblenet.net), or the writer, cohesion (cohesion@invisiblenet.net).
The following people get our heart felt kudos for devoting their valuable time and resources to this project:
Copyrights are held by the respective authors. Anything not explicitly copyrighted in the code base is copyright 0x90.
Changes in fundamental network architecture increment the first numerical position (x.0.0). The addition of features increments the second numerical position (0.x.0). Non-function-altering bug fixes increment the third numerical position (0.0.x).
This document's revision numbers correspond to the projects first two numbers. Changes of this document occur when an increment of either of the first two positions occurs, that is, if any program functionality changes. If the current revision is 1.1.23, this document should be labeled and updated accordingly to 1.1.x. The third position indicates the editorial revision. If this is the second revision of this document for version 1.1.x of the software, the document revision number is 1.1.2
Our goal is to incrementally move toward an increasingly distributed network. Version 2.0.0 should be completely distributed and autonomic.
See the OS specific instructions below.
Client access specifies the IP addresses that are allowed to connect to your proxy. Most users will only allow themselves to connect to their proxy, however, if you wish to act as a tunnel for a friend, you will want to add his IP address to this list. If you are a public relay, all IP addressess are automatically allowed to connect.
Port specifies the port incoming connection are allow on. If port 7777 is specified, you will need to tell your IRC client to connect to localhost:7777.
Getting node.ref by IIP specifies that the software will update its list of public relay server every time it successfully connects to the IIP network.
Getting node.ref by HTTP and Get node.ref now retrive the node.ref from a web server, and, since the web is not anonymous, this method is not anonymous. You may only need to do this if for some reason your node doesn't seem to be able to find any relays anymore. Check all other possibilities (such as network compromise) before using this option.
The software for the windows environment comes in a single executable Nullsoft installer file. Download and execute the installer following hte on screen instructions. After install, IIP will automatically be excuted. Upon initializing, the software will check for the presence of it's configuration files and, if they are not present, will create them in the folder it's residing in. These configuration files are user editable and we encourage you to explore them. For simple configurations, however, use the GUI that appears upon first run or, at a later time, by right clicking the IIP icon in the system tray and selecting 'Settings'.
After file creation and configuration is complete, IIP will appear in the system tray on your taskbar and remain there as long as the proxy is running. You may now start your IRC client and connect to localhost on the port you opened. For instance
/server localhost 7777
After a few tries, you should be connected to the network. See the Trent section on setting up your username and perhaps creating a new channel. I suggest joining channel #anonymous and getting to know your fellow IIPers.
Compile requirements:
$ make isproxy
The compilation process is relatively short. Once complete, type:
$ ./isproxy
The first time the software is executed, a command line interface similar to that of the GUI Windows version will appear. Use the letters that correspond to the options on the menu to navigate through the system.
Once configuration is complete, the program will load and you will be returned to the system prompt.
Reconfiguring causes isproxy to restart, so you will be booted from the network for a moment. If you need to reconfigure:
$ ./isproxy -C
You might decide to contribute your resources to the vitality of the network. If so, you must understand how important it is that you system is always online and available to recieve connections.The quality of other people's experience depends on the reliability of the relay nodes. Reargeless of your OS don't forget to open a the correct port on your firewall!
If you have fairly stable connection and would like to contribute to the network's virility, you could run a relay. All it requires is a computer that is connected to the internet all of the time and a little setup.
Be sure to add IIP to your Start Up group so that in the event of power failure, IIP will come immediately back online.
The *nix config is largely similar to that of the Window's. Instead of a GUI
chocolate's iipconfiggen stuff goes here.
By mids (mids@invisiblenet.net)
usermanual.html, v1.4.2 (http://trent.invisiblenet.net)
Trent is the service for IIP that controls nick and channel control. It is like the chanserv and nickserv that some other IRC networks have. Additionally it has some special features for the Instant Messenger.
The main purpose of Trent is to authenticate while keeping your anonymity. Gimmicks like auto-op and auto-voice lists are not implemented (and not planned to).
The user has some responsibility on security. Don't forget your password nor pick an easy one. There is no way to change it. If you give untrustworthy persons access to your channel with a high level, you might risk to loose it.
Nicknames and channels don't wear out, unless you drop them. In the future there might be period of inactivity after which your nick will be dropped.
The correct way to address Trent depends on your IRC client. Trent listens to the SQUERY command specified in RFC 2812. Not all IRC clients know that command or use it correctly. Both IRC commands and Trent commands may be upper- and lowercase, Trent can also be spelled in lowercase.
If you are lucky, your IRC client works like this: /squery Trent
command arguments
Otherwise you could try: /squery Trent :command arguments
This should always work: /quote squery Trent :command
arguments
These are the most important commands for everyone. You should learn them thoroughly:
/squery Trent HELP <optionalcommandname>/squery Trent NICKREG <password>/squery Trent IDENTIFY <password>/squery Trent NICKSTATUS <nick>Info about the administrative contact
Add nick to channel access (level 2)
Remove nick from channel access (level 2)
Drop the channel
Info about channel
Sets the access level for a nick on channel (level 2)
List nicks with channel access
Register channel
Sets the channel website (level 2)
Deop everyone in the channel (level 2)
Rename the nick, gives you your original nick back
Help about commands
Identify with current nick
Info about the service and programmers
Drop the current registered nick
Info about nick
Register current nick
Sets your website
Gives registration/identification status
Op you in channel (level 1)
The purpose of this project is not to facilitate the evil, but to protect the capacity of individuals living in oppressive environments to communicate. IIP is a tool for communication just like your phone is a tool for communication. While it may be used for destructive endeavors, our belief is that far more good than bad will come of this.
See these excellent papers on the subject of freedom of expression and facilitating communication.
[to be done]
The network architecture is pretty self-explanatory from the docs above so this section will focus mainly on the intricacies of specific features such as encryption and dynamic node update.
Selections from UserX's emails on the subject:
Hopefully this little diagram helps make things a little clearer in
regards to the direction in which backPipe goes in a chain of pipes.
pipe pipe pipeface
sock crypt spurt raw
+-----------+ +-----------+ +-----------+ +-----------+
NULL<----backPipe |<----backPipe |<----backPipe |<----backPipe |
|forwardPipe--->|forwardPipe--->|forwardPipe--->|forwardPipe--->NULL
+-----------+ +-----------+ +-----------+ +-----------+
The short description of the backward pipe is that it reverses the
direction of the previous pipe (the one to the left on a protocol
parameter).
A normal crypt pipe in action:
protocol = crypt:raw
+------+ +------+ +------+
in--->------>---->------>---->-->in |
|socket| |crypt | | raw |
out---<------<----<------<----<--<out|
+------+ +------+ +------+
A crypt pipe that has been made backwards:
protocol = crypt:backward:raw
(the A, B, C, D pairs are joined)
+--------------------+
| backward |
+------+ | +------+ | +------+
in--->------>---->-A C->------>-D B->---->-->in |
|socket| | |crypt | | | raw |
out---<------<----<-C B-<------<-A C-<----<--<out|
+------+ | +------+ | +------+
+--------------------+
One use for the backward protocol is to perform a local test of a
pipe.
protocol = crypt:backward:crypt:raw
\-----\ /-----/ +----+
client--->crypt>-<crypt<--|node|
/-----/ \-----\ +----+
Another use for it is to achieve end-to-end encryption.
This is achieved by putting crypt:backward in the protocols
of the listen noderef for entry into the network (what irc
clients connect to) and the final exit noderef (the one that
connects to ircd).
how things are with IIP v1.0
[user] [relay] [server]
|-iip----------| |---------iip----------| |---------iip--|
| | | | | |
|+----+ \-----\| |/-----/ +----+ \-----\| |/-----/ +----+|
irc--|node|-->crypt>-net-<crypt<--|node|-->crypt>-net-<crypt<--|node|--ircd
|+----+ /-----/| |\-----\ +----+ /-----/| |\-----\ +----+|
|--------------| |----------------------| |--------------|
how things will be with IIP v1.1
[user] [server]
|----------iip----------| |---------iip-----------|
| | | |
|\-----\ +----+ \-----\| +-----+ |/-----/ +----+ /-----/|
irc--->crypt>-|node|-->crypt>-net-[relay]-net-<crypt<--|node|-<crypt<---ircd
|/-----/ +----+ /-----/| +-----+ |\-----\ +----+ \-----\|
|---^-------------------| (relay same |-------------------^---|
| as above) |
backward backward
IIP contains two layers of encryption.
When a node connects to the network, whether it's a user, relay, or broadcast server, there is an encrypted connection that is established. The encryption used is 128-bit Blowfish Cipher and session key is exchanged between nodes via Diffie-Hellman Public Key Exchange Protocol. So every node that connects to another node must handshake. Every relay node that a client may connect to has a static 1024-bit Public Key attached to it for identity reasons. When another node connects to that public relay, it handshakes using the known public key that is contain in the node.ref. Example node.ref entry:
host = iip.relay.com port = 1796 protocol = crypt:raw publickey = ffb0d51c03a9149696730b739eb2472f7b051b59dd16 e11eec49e329de597e5f07bd4290f717b2c7ce86951ae6b6eda2e859 afa8484f67067dea46f9466a4370e925d624f32707a9e90c4135e009 d4beb87883b9617208c8c0c56ad424748e976a2aed3830581ccb185a bc6025547da2d201ce538a3001d898d886089ddfb7e8
The Diffie-Hellman Key Pair is generated using an implementation of Yarrow (a secure pseudo-random number generator - http://www.counterpane.com/yarrow.html) and from that point, a Diffie-Hellman shared key is calculated for the private Blowfish session key which will is implemented throughout the node to node encrypted connection. Each node does this routine per connection. If the node that it connects to does not respond to the public key that the connecting user expects from the relay, the connection is terminated and considered invalid. This is done throughout the network all the way up to the IRCd server. The main purpose of this is to protect the privacy from outside monitoring connections. This will not protect you from an "evil" node deciding to decrypt the messaging inside and monitoring his connection for messages. Hence the reason for the end to end encryption.
To solve the above problem, we added a network ID to the broadcast layer
which is also a static 1024 bit public Diffie-Hellman Key which is placed at
the top of the node.ref file as well as the protocol type, which is
spurt:backward:crypt:backward:core. Spurt:backward
is the fake chat size messaging protocol telling IIP to understand how that
works without interfering with IRC server; crypt:backward is the
cryptographic protocol also understanding the fake traffic (the backward is
the traffic interpreter and director), and core is the raw IRCd
server. Example of node.ref file with Network ID and node to node
encryption.
networkid = ffb0d51c03a9149696730b739eb2472f7b051b 59dd16e11eec49e329de597e5f07bd4290f717b2c7ce86951a e6b6eda2e859afa8484f67067dea46f9466a4370e925d624f3 2707a9e90c4135e009d4beb87883b9617208c8c0c56ad42474 8e976a2aed3830581ccb185abc6025547da2d201ce538a3001 d898d886089ddfb7e8 networkprotocol = spurt:backward:crypt:backward:raw host = iip.relay.com port = 1796 protocol = crypt:raw publickey = 8484f67067dea46f9466a4370e925d624f32707 a9e90c4135e009d4beb87883b9617208c8c0c56ad424748e976 a2aed3830581ccb185abc6025547da2d201ce538a3001d898d8 86089ddfb7e8ffb0d51c03a9149696730b739eb2472f7b051b5 9dd16e11eec49e329de597e5f07bd4290f717b2c7ce86951ae6 b6eda2e859afa
So in this case, every node executes a key exchange and private session encryption in the same manner as the first layer, but this time it's exchanging it with the network broadcast layer which will encrypt the traffic from beginning point to end point throughout the network. Each node does this that is on the network, thus preventing reading of information being decrypted by relays, and making it less necessary to trust relays on the network.
In addition to just relying on standard encryption, we have implemented
certain extra measures for prevention of traffic analysis and anonymity. We
have implemented fake traffic which spurts throughout the network appearing
to come from user clients on the network. Also, we XOR every 8 bytes of
traffic so that you cannot analyze the encryption text. (e.g: Someone says
test and it looks like 9z9s09er in ciphertext. If
they repeat the word test, it will look completely different in ciphertext
rather than the same 9z9s09er you saw before. Also, every 52
blocks of traffic (messages sent, fake or real), we rotate the session key
with a new one generated from the shared key info so that both sides will
negotiate trivially and without any notice on the network. This imposes a
constantly moving key system which helps protect the privacy, integrity and
security of the traffic on IIP. All of this is executed on both layers, end
to end, and node to node.
In order to ensure that clients have a consistently good connection to the network, it's important to keep the node.ref up to date with the most accurate information about the status of the network. This is done two ways:
When the end to end handshake occurs, nodes receive a short data stream from the IRCd server that contains the latest node.ref. The ability to disable this feature may be included in future versions.
Currently, when a node elects to become a relay, a message is sent upsteam to the IRCd server identifying it's host name, port number accepting connections, and its public key. The server periodically checks a relay for it's status. If the relay is found to be non-functioning for a certain period of time, then the relay is removed from the node.ref that the IRCd server is sending to users joining the network. These rules are called the Strict Contact Probability Algorithm and are implement to increase the reliability of the network.
Nothing down here to see. Move along, move along...