<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 crypto happening?

<0x90> To bootstrap into the network each node has these settings:
host
port
protocol = crypt:raw
public key = with a 1024-bit (default) Diffie-Hellman public key.

What happens then, utilizing Yarrow pseudo random number generator (http://www.counterpane.com/yarrow.html ) 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 bit, 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 end-to-end.

I'm going to describe next what is implemented as of RC2. Now from this point once you've authenticated you have one more step.

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 key.

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 connecting in.

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 decentralized version.

<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 plaintext.

But the ircd server is sitting on a localhost port, just like your node is (accessed via a localhost port) which means it is unsniffable.

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 conversations.

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 not work.

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 you say.

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 optimal.

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 next.

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 IRC Bot?

<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 IIP.

[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 party.]

<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 verification?

<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 PGP).

<0x90> Yes.

<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 also).

<0x90> Yes.

<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 would think:

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 the users.

<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 channel.

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 happen.

<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 about this?

<0x90> Yes. The text might have been misconstrued from what I was saying, but IIP can handle arbitrary Persistent TCP connections.

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 routing table.

<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 networkprotocol).

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 either one.

<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 Protocol.

<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 Project.

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.
A streamlined 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: info@distributedcity.com

0x90 / nop can be contacted at 0x90@invisiblenet.net (PGP key ).

Invisible Man can be contacted at invisible_man@citystateinc.com (PGP key).