<DC> Okay, we covered quite a lot of ground so far, let's
focus now on how the technology works in more detail and the future
of the Invisible IRC project.
Can you give us a more detailed technical explanation or what
happens when a node connects to the Invisible IRC network and the
<0x90> To bootstrap into the network each node has these
protocol = crypt:raw
public key = with a 1024-bit (default) Diffie-Hellman
What happens then, utilizing Yarrow pseudo random number generator
) it selects a node to connect to (the more nodes in your routing
table the better). Then it handshakes with the public key to that
node, and also in your node.ref is a
network id = 1024
public key = as well this sits at the Invisible
ircd server (localhost as well) and is the end-to-end key that
provides authentication and also secures your communication
I'm going to describe next what is implemented as of RC2. Now
from this point once you've authenticated you have one more
Upon each session the user also creates a temporary 2048-bit
Diffie-Hellman key to handshake with, for end to end as well, and
is securely deleted from memory and swap when the session has
completed. This is done as the last step once authenticated.
The reason for this is that if one were to play spy node and log
your session they can not find the IRCD server operator and decide
that his network id key would give them the jewels of the kingdom.
It won't, because no one has the 2048-bit temporary session key set
that was established upon the irc session. This covers the use of
the asymmetric crypto (Diffie-Hellman and friends).
Now for symmetric session encryption: We are using 128-bit
blowfish for node-to-node and end-to-end up to authentication. Then
with the temporary key set we are using a 160-bit session key
generated from a SHA-1 hash of the key exchange of the 2048-bit DH
This ensures the randomness of the key generated, as that is the
most important key of all. Also for further protection we have the
RKA (something we came up with, and I will explain in a moment), as
well as using Cipher Block Chaining.
We also have fake traffic 'chaffe' that is randomly generated,
sent out as traffic padding as to hide node activity from traffic
analysis and sniffers.
So, a node is always looking active in some way, messages cannot
be proven to be coming from your node specifically, since messages
are coming from every node and there is no way to know what is a
real message and what is the fake traffic.
RKA is the Rotating Key Algorithm. The spurt of fake traffic
aids RKA. What this is, is every 52 blocks (blocks == 64 bit
encryption blocks, aka messages) we rotate the session key with
random data from the previous session.
With the fake messaging pushing out blocks. This averages to be
about every 10-20 seconds. In the future we will have an 8 key set
(right now it is set at 1, but is easily modified in the code to do
as many as you want, this will be implemented as we update our
multi-precision library to be faster) which what that will do is
generate 8 keys to use and then xor those 8 keys into themselves
generating another set of 8 keys.
8 keys is defined as 128-bit keys for node to node and 160-bit
for end-to-end. This will require 8 keys for approximately every 2
minutes of data. So 2 minutes of data cracking wise would have to
be 8 * 160-bit keys + 8 * 128-bit keys, plus you have to capture
all data from the start of session to achieve this or you may as
well stop right now.
Plus utilizing CBC we have xor'd every 64-bit block with the
last block so typing 'ABCD' the first time won't be the same
ciphertext as 'ABCD' the next time.
As we implement the new multi-precision library our key bit
sizes will be much higher and our encryption algorithms will also
be user selectable. For instance you can choose to use AES,
blowfish or TwoFish, etc.
<DC> You used the terms end-to-end and node-to-node
encryption. What constitutes a "node" and an "end"?
<0x90> A "node" is anyone connecting into the IIP network.
Each node in this context is isproxy software running on the node
which also provides relay service.
Look at it this way, a "node" connects to another "node",
literally. The two computers running isproxy have established a
communication stream under the defined encryption protocol, thus
"node to node" encryption.
<DC> Okay, so node to note means my node, to the node
that I am connected to each handling its own crypto, then from that
node to the next in the same way, and so on.
<0x90> Yes. Now the "end" is our network server, hidden in
the muck of all this. Somewhere down the line you get to meet it by
That is the communication between you and the server directly.
So in this case "end-to-end" refers to the communications tunnel
from your node all the way through to the "end" - the server
running the IRCD. Thus "end-to-end" encryption.
<DC> Okay, and in this case, the "end-to-end" means
basically another set of crypto that is from my end (node) to the
actual ircd server?
<0x90> Yes. This is the first layer. Together, the
"node-to-node" and "end-to-end" encryption actually creates two
layers (3 really) but we'll get to that later.
<DC> Node-to-node and end-to-end encryption seems to be
clear to us. Does IIP currently have user-to-user (P2P) private
message encryption or channel encryption?
<0x90> At this time no. This is in the works with the
<DC> Well, let me clarify that a little more, the way
it sounds is that there is encryption happening at the node-to-node
and end-to-end, but all IRC messages, private and channel are
plaintext on the IRCD server, is this correct?
<0x90> No, not exactly. Everything is plaintext at any
end-point, just as what you see in your IRC client is
But the ircd server is sitting on a localhost port, just like
your node is (accessed via a localhost port) which means it is
IRC private messages are truly private and cannot be intercepted
or monitored, and channels that are invite only or locked are
private as well. At the ircd server if an evil sysop choose to,
could live log this and understand the communication - just as much
as you can live log something on your end on your
However, and this is crucial - logging if it were to be done
does not pinpoint who the heck that person is, so if you logged on
your node end or it was done at the ircd it still wouldn't give out
much information, other than the fact that something was said. Not
who said it, or where they are.
Now, we do not log our servers and you'll have to trust me on
that at this time. We have enabled extra crypto to prevent logging
relays and so attacking the server and replaying the messages will
In the future for essential true privacy we plan to implement
user-to-user (P2P) authentication and channel encryption.
<DC> So private messages cannot be intercepted by the
ircd operator even now?
<0x90> Technically only if live logging is enabled, not by
sniffing or anything. In the source code of the ircd we use we have
disabled the ability to log, and you can't sniff the connection in
plaintext. This is still using end-to-end technology at the relay
layer, just not decentralization yet.
<DC> Okay, you said technically only if live logging is
enabled in the ircd. We will have to trust you on that. For now,
those of us that know you have a level of trust in you, but this
underscores the need for a true IIP decentralized implementation as
In this future system, what happens when we connect our IRC
client to the proxy we are running?
<0x90> The design is when you connect your irc client to
the iip proxy you will have "tricked" your irc client into thinking
it's talking to an ircd server. Reality is it's not. It's talking
to a protocol interpreter, a middle man as you would say, between
the irc client and the iip protocol.
This future system looks like this:
User client --> virc --> iip protocol --> network
The current system looks like this:
User client --> iip proxy localhost pipe --> iip protocol
magic encryption does it's stuff --> network
In the future the virc will be the what is now the localhost
pipe, as it will emulate all needed responses to and from the irc
client. The virc will also have a terminal where you can /msg
isproxy and it will bring you to a terminal type menu in a private
message box where you can change settings, set up your own routes,
choose encryption algorithms, regulate the traffic padding options
etc. You can even set up your own channels and more.
Now I will give a general layout of what the network will look
like. Not a too technical layout that could take forever.
Optional clear text channels (usually public channels) will be
there, just like normal irc. You will have keyspace channels which
will be most likely hashes of some sort or public keys. Users will
join those channels through invite or word of mouth as they are
privately controlled channels.
Now on the network each channel is treated like a network, a
space of your own that you can do what with, run whatever transport
agents (webservers, for one example) etc.
The decentralization will aid and improve the routing of the
network, as we can use a spread spectrum type routing method to
send messages down multiple pipes adding super confusion to any
traffic analysis that would be running we will be improving all
traffic chaffe and padding decentralization will allow us to do so
much more. The network will always be moving and redundancy will be
It will be a "living, breathing, self-sustained network" that
users can adopt and live on if they would want, providing the
ultimate in invisibility, privacy, security, anonymity, and
communication. It's not an easy task, and it's a big project but
you have my word, I don't deliver vaporware, and I refuse to.
Utilizing this protocol, and with the modular code we have
designed you also will be able to interchange and fit in other
protocols (routing and the like) right into the proxy. Say you want
also high volume, static content as well (distributed file sharing
system), it will be very simple.
This will define the epitome of the Internet when we're done
which I don't think we'll ever be done because it's always up for
improvements, but that's what we like.
On the topic of Peer 2 Peer protection: Utilizing invisibility
and anonymity to protect security. Our standards need to be raised.
I believe Invisible IRC Project's goal in the security application
and protocol field, will hopefully do this, and educate many
through the process.
<DC> Wow, this is very thought provoking stuff. One of
the reasons we wanted to do this interview is because we were aware
of some of these ideas, as some of them were mentioned in the
CODECON speech you gave earlier this year, and also some of the
talk on Invisible IRC Project/IRC #channels.
<0x90> Yes. There is an mp3
file and .txt
transcript of that presentation at CodeCon 2002 available from the Invisible IRC Project
website. I also will be speaking at ToorCon in September.
<DC> Okay, let's talk about authentication of identity
We know we are anonymous, but currently what measures are in
place that can help ensure that I am really talking to nop or my
other associates on IIP?
<0x90> At this time we have Trent, which is also in very
beginning stages. He is our authorization agent and you can
register your IRC nick, similar to chanserv. Unfortunately it uses
symmetric passwords. We plan to make it a public key server.
Users will generate a public key and be user@publickeyid. This
will be a challenge response authentication system utilizing public
key digital signatures.
<DC> Where is Trent? Is it part of the ircd? is it an
<0x90> It is an IRC service that is operated by a 3rd
party volunteer on IIP. The database is encrypted and hashed, and
the 3rd party volunteer is a distinguished member and developer of
[Editors note: The name 'Trent' comes from traditional
cryptographic literature. In these texts, the authors customarily
use the same set of participants to illustrate their examples when
describing cryptographic protocols. Alice is traditionally the
first participant in the protocol being described, Bob is the
second. Eve is always the sneaky eavesdropper, and Mallory
Malicious is always cast as the active snooper who attempts to
discover the secret messages via cryptographic attacks. Trent is
known as the Trusted Arbitrator in protocols which require such a
<DC> If Trent were to move from passwords to a public
key system, why would we need Trent? It seems like the
authentication system using a public key system is similar to a PGP
system. With that being the case, wouldn't we would each
individually be our own Trent, and assign trust to the keys we know
and exchange? Using a PGP Web of Trust system for key
<0x90> Yes you would be. Trent is our solution for the
current centralized system. When we decentralize, the virc will
handle all of that.
<DC> Okay, so if we all had our own Trent managing public
keys of other users, it seems like this is integral to P2P
encrypted messaging, since we would have a public key
infrastructure in place, and keys to encrypt messages to (as per
<DC> This makes a lot of sense. Two birds killed with
one stone. (I guess that is 3 birds.) Just like PGP helps with
encryption, authentication to (valid public key of recipient) and
authentication from (signing of messages with our keys
<DC> Channel Encryption is defined as being able to
have a standard IRC Channel, where only certain recipients are able
to read the messages of the channel.
So even if someone joined the channel, they would not be able
to understand the conversation. Think of it as PGP-secured group
conferencing. There are two ways this might be typically done I
1) Every message sent to the channel is encrypted to every
channel member's public key (very expensive in CPU cycles).
2) Give the channel its own keypair, and share that with all
<0x90> Well there are other methods. Channel keypair is
the most likely method, but there are ways of of doing it where a
userid can be included in the list of authenticating users that are
allowed to handshake with this key.
So if you are trusted for the channel you will handshake and
negotiate a session key for the channel. Each user in turn will
have different session keys and the channels will be defined as end
points so this would secure end-to-end encryption, from user to
You would have a list of allowed keys that you would set your
channel with so as you invite people the /invite command would auto
tag that to the channel key these keys would rotate most likely
every week as recommended. In this instance, the CPU cycle is not
intensive because like PGP you are just using that for encrypting
and calculating the session keys which once established, is trivial
on CPU cycles.
<DC> Will channel encryption be implemented as an
add-on so to speak, to the normal P2P messaging encryption? Or does
it belong somewhere else?
<0x90> It will be a major essential part of the network
there will be non-encrypted channels, also known as public
channels, like I believe #anonymous could most likely be
non-encrypted. or... possibly encrypted but allowing all keys.
So we may just encrypt all channels with some having an auth
mode and some are just plain public. Then you just handle the
session as users join the channel. These modes can easily be
established. We will be taking a feature request list soon.
<DC> In your early-2002 CodeCon speech, you mentioned
that the P2P public key system would be run as a separate user
application, and not directly in the Invisible IRC Project isproxy
that users run.
<0x90> For the current centralized IRCD version, that is
the only way so far, but when decentralized, we plan to implement
that as all part of the isproxy.
<DC> Aha. Perfect. Okay, I see we are mixing some ideas
from the current implementation and the future.
<0x90> Yes. Channel encryption is future. You have to
remember centralization has limits. We need to decentralize in
order for the full onslaught of the IIP vision to be able to
<DC> On the IIP Internet site, and in some of the
documentation, we read something about IIP not being limited to IRC
but that you have successfully run tests of an IIP network running
Shoutcast mp3 streaming over the iip protocol? Can you tell us
<0x90> Yes. The text might have been misconstrued from
what I was saying, but IIP can handle arbitrary Persistent TCP
At this time you can put any server and any client on it that
has a TCP port open and maintains a consistent connection with the
client during a session.
We are essentially developing a secure and anonymous P2P
transport protocol. Transparent mind you. That's key.
<DC> This is interesting, so it suggests that the
current isproxy that we are all running on our systems actually has
no IRC specific protocol hooks in it, or no?
<0x90> Correct, it has no specifics to IRC, but it has
specifics for a persistent connection from point A to point B. Also
there is the NodeSend pipe that will securely send you the dynamic
<DC> How many end connections from point A to C (end)
does the isproxy currently handle? Meaning point A to B and point A
to C. B and C being two separate networks and end points within the
Invisible IRC Project.
<0x90> Yes. You can do this but you have to tell your
isproxy client which network you would like to be on. We have (in
RC2 specifically) in the node.ref routing table: networkname and
networkversion options (as well as networkid and
This will allow by choice multiple connections, or (what we
really designed it for) was use with upgrades on networks or to
have optionally your friends IIP network and then the main one and
you could tell IIP which to connect to or two randomly connect to
<DC> Can you connect to both networks at the same time?
More than one at the same time?
<0x90> At this time no. You could technically in the sense
of having the isproxy process run twice or your IRC client running
twice with new directions but not really.
<DC> Okay, for right now IIP has a fixed endpoint, the
IRCD in its current configuration.
<0x90> Yes. This is temporary, but the most viable
solution in a semi-centralized environment.
<DC> Is it possible to take the IIP net system as it
is, and swap out the ircd with an HTTP web server?
<0x90> HTTP web server depending on persistent
connections currently, no, but with a little modification, yes.
Mostly by taking out the delay protocols and a couple of other
things. So, yes, it would be possible, and we have future plans in
this area of course.
<DC> One of the most frequent asked questions by avid
IRC users is how they can send files to other IRC users with the
IRC protocols DCC and CTCP. Can you quickly explain to our readers
what DCC and CTCP are and if they work in IIP?
<0x90> DCC would be Direct Client Connections and CTCP is
Client to Client protocol. In the centralized version of IRC DCC
would have to request the IP address on both sides as well as CTCP
activity. Being DCC utilizes CTCP for the request the main problem
we saw, right off the bat, was obviously our goal is anonymity and
privacy and DCC is directly not that.
In the decentralized version the plans are to be able to support
this with the implementation of a Freenet protocol for exchange of
files, this will take us a step towards Invisible Internet
<DC> So file transfers to other users on IIP would be
initiated on IIP, but would use the Freenet system to actually
perform the sending and receiving by the other party?
<0x90> Yes. Utilizing the dynamic content to point to the
static content IIP --> Freenet --> IIP ack file sent.
<DC> Would users need to be running a local Freenet
node to send and receive files?
<0x90> No. We plan to implement it in the IIP protocol.
ANSI C is a nicer language to do this in and is less of a resource
hog than Java and is, of course, our optimal language.
<DC> Well, 0x90, thank you so much for the several
hours you took out of your time to answer some of our questions and
let us know more about what is happening with the Invisible IRC
Many of us at Distributed City would like to thank you and
your team for the great work you have done so far. We were looking
for a secure chat solution for our community, and since we saw the
Invisible IRC Project and experienced it, many of us use it every
day, and conduct quite a bit of business on it.
We look forward to the future of IIP, and hope we can
continue to contribute in various ways that we can, to further
these ideas and technologies.
Distributed City is a Nexus of Sovereign Individuals.
community environment that provides News, Forums, Weblogs, OpenPGP
Messaging, and anonymous chat (IIP) to members.
Membership is currently by referral of an existing member only.
Distributed City maintains the IIP/IRC channel: #distributedcity
For more information: firstname.lastname@example.org
0x90 / nop can be contacted at email@example.com
Invisible Man can be contacted at firstname.lastname@example.org